More Praise for Scrum: The Art of Doing Twice the Work 
in Half the Time 


“This extraordinary book shows a new way to simplify your life and work, 
increase your focus, and get more done in less time than you ever thought 
possible.” 


—Brian Tracy, bestselling author of Eat That Frog! and Time Power 


“Groundbreaking ... Will upend people’s assumptions about how productive 
they can actually be.... Jeff Sutherland discloses to the non-tech world the 
elegantly simple process that programmers and web developers have been using 
since he invented Scrum, showing how a small, empowered, and dedicated team 
can deliver significantly higher quality work at a faster pace through 
introspection, iteration, and adaptation.” 


—Michael Mangi, senior VP of interactive technology, Social@Ogilvy 


“Jeff Sutherland has written the essence of Scrum for the masses. This book 
elevates Scrum from a fix-it tool to a way of life.” 


—Hirotaka Takeuchi, professor of management practice, Harvard Business 
School 


“Jeff Sutherland isthe master of creating high-performing teams. The 
subtitle of this book understates Scrum’s impact. If you don’t get three times the 
results in one-third the time, you aren’t doing it right!” 


—Scott Maxwell, founder and senior managing director, OpenView Venture 
Partners 


“Jeff Sutherland used the common-sense but seldom-applied principles of the 
quality movement, user-centered design, and lean development to come up with a 
process that dramatically increases productivity while reducing employees’ 
frustrations with the typical corporate nonsense. This book is the best 
description ve seen of how this process can work across many industries.” 


—Jeffrey Pfeffer, professor, Stanford Business School and co-author of The 
Knowing-Doing Gap 


“Sutherland’s secret to surmounting professional and personal obstacles is 
approaching tasks with deliberate attention and a resilient mindset. This book 
will change the way you do everything. Even better, it will help you feel good 
in the process. Just read it, and get more done.” 


—Arnold V. Strong, CEO of BrightNeighbor.com, and colonel, US Army 
Reserve 


“This deceptively simple system is the most powerful way I’ve seen to 
improve the effectiveness of any team.” 


—Leo Babauta, creator of Zen Habits 
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Preface 
Why Scrum? 


I first created Scrum, with Ken Schwaber, twenty years ago, as a faster, more 
reliable, more effective way to create software in the tech industry. Up to that point— 
and even as late as 2005—most software development projects were created using the 
Waterfall method, where a project was completed in distinct stages and moved step by 
step toward ultimate release to consumers or software users. The process was slow, 
unpredictable, and often never resulted in a product that people wanted or would pay 
to buy. Delays of months or even years were endemic to the process. The early step- 
by-step plans, laid out in comforting detail in Gantt charts, reassured management that 
we were in control of the development process—but almost without fail, we would 
fall quickly behind schedule and disastrously over budget. 


To overcome those faults, in 1993 I invented a new way of doing things: Scrum. 
It is a radical change from the prescriptive, top-down project management 
methodologies of the past. Scrum, instead, 1s akin to evolutionary, adaptive, and self- 
correcting systems. Since its inception, the Scrum framework has become the way the 
tech industry creates new software and products. But while Scrum has become 
famously successful in managing software and hardware projects in Silicon Valley, it 
remains relatively unknown in general business practice. And that is why I wrote 
Scrum: to reveal and explain the Scrum management system to businesses outside the 
world of technology. In the book I talk about the origins of Scrum in the Toyota 
Production System and the OODA loop of combat aviation. I discuss how we organize 
projects around small teams—and why that is such an effective way to work. I explain 
how we prioritize projects, how we set up one-week to one-month “sprints” to gain 
momentum and hold everyone on the team accountable, how we conduct brief daily 
stand-ups to keep tabs on what has been done and on the challenges that have 
inevitably cropped up. And how Scrum incorporates the concepts of continuous 
improvement and minimum viable products to get immediate feedback from 
consumers, rather than waiting until a project is finished. As you'll see in the pages 
that follow, we’ve used Scrum to build everything from affordable 100-mile-per- 
gallon cars to bringing the FBI database systems into the twenty-first century. 


Read on. I think youll see how Scrum can help transform how your company 
works, creates, plans, and thinks. I firmly believe that Scrum can help to revolutionize 
how business works in virtually every industry, just as it has revolutionized innovation 
and speed to market at a dazzling array of new companies and a breathtaking range of 
new products emerging out of Silicon Valley and the world of technology. 


—Jeff Sutherland, PhD 


CHAPTER ONE 


The Way the World Works Is Broken 


Jeff Johnson was pretty sure it wasn’t going to be a good day. On March 3, 2010, the 
Federal Bureau of Investigation killed its biggest and most ambitious modernization 
project—the one that was supposed to prevent another 9/11 but that had devolved into 
one of the biggest software debacles of all time. For more than a decade the FBI had 
been trying to update its computer system, and it looked as if they would fail. Again. 
And now it was his baby. 


He’d shown up at the FBI seven months earlier, lured there by the new Chief 
Information Officer, Chad Fulgham, whom he’d worked with at Lehman Brothers. Jeft 
was Assistant Director of the IT Engineering Division. He had an office on the top 
floor of the J. Edgar Hoover Building in downtown Washington, D.C. It was a big 
office. It even had a view of the Washington Monument. Little did Jeff know he’d end 
up in a windowless cinder-block office in the basement for much of the next two 
years, trying to fix something that everyone believed to be unfixable. 


“It was not an easy decision,” Jeff says. He and his boss had decided to declare 
defeat and kill a program that had already taken nearly a decade and cost hundreds of 
millions of dollars. By that point, it made more sense to bring the project in-house and 
do it themselves. “But it needed to be done and done well.” 


The project was the long-awaited computer system that would bring the FBI into 
the modern age. In 2010—the era of Facebook, Twitter, Amazon, and Google—the 
FBI was still filing most of its reports on paper. The system the Bureau used was 
called the Automated Case Support system. It ran on gigantic mainframe computers 
that had been state of the art sometime in the eighties. Many special agents didn’t even 
use it. It was just too cumbersome and too slow in an era of terror attacks and swift- 
moving criminals. 


When an FBI agent wanted to do something—anything, really—from paying an 
informant to pursuing a terrorist to filing a report on a bank robber, the process wasn’t 
that different from what it had been thirty years earlier. Johnson describes it this way: 
“You would write up a document in a word processor and print out three copies. One 
would be sent up the approval chain. One would be stored locally in case that one got 
lost. And with the third you'd take a red pen—I’m not kidding, a red pen—and circle 
the key words for input into the database. You’d index your own report.” 


When a request was approved, that paper copy would drift down from upstairs 
with a number on it. A number written on a piece of paper is how the FBI kept track of 
all its case files. This method was so antiquated and porous that it was blamed in part 


for the Bureau’s failure to “connect the dots” that showed various Al Qaeda activists 
entering the country in the weeks and months before 9/11. One office was suspicious 
of one person. Another wondered why so many suspicious foreigners were getting 
flight training. Another had someone on a watch list but never told anyone else. No 
one in the Bureau ever put it all together. 


The 9/11 Commission drilled down after the attack and tried to discover the core 
reason it was allowed to happen. Analysts, said the Commission, couldn’t get access 
to the very information they were supposed to analyze. “The poor state of the FBI’s 
information systems,” reads the report, “meant that such access depended in large part 
on an analyst’s personal relationships with individuals in the operational units or 
squads where the information resided.” 


Before 9/11, the FBI had never completed an assessment of the overall terrorism 
threat to the United States. There were a lot of reasons for this, from focus on career 
advancement to a lack of information sharing. But the report singled out lack of 
technological sophistication as perhaps the key reason the Bureau failed so 
dramatically in the days leading up to 9/11. “The FBI’s information systems were 
woefully inadequate,” the Commission’s report concludes. “The FBI lacked the ability 
to know what it knew: there was no effective mechanism for capturing or sharing its 
institutional knowledge.” 


When senators started asking the Bureau some uncomfortable questions, the FBI 
basically said, “Don’t worry, we have a modernization plan already in the works.” 
The plan was called the Virtual Case File (VCF) system, and it was supposed to 
change everything. Not letting any crisis go to waste, officials said they only needed 
another $70 million on top of the $100 million already budgeted for the plan. If you go 
back and read press reports on VCF at the time, you'll notice that the words 
revolutionary and transformation are used liberally. 


Three years later, the program was killed. It didn’t work. Not even a little bit. 
The FBI had spent $170 million in taxpayer money to buy a computer system that 
would never be used—not a single line of code, or application, or mouse click. The 
whole thing was an unmitigated disaster. And this wasn’t simply IBM or Microsoft 
making a mistake. People’s /ives were, quite literally, on the line. As Senator Patrick 
Leahy of Vermont, then the ranking Democrat on the Senate Judiciary Committee, told 
the Washington Post at the time: 


We had information that could have stopped 9/11. It was sitting there and was not 
acted upon.... I haven’t seen them correct the problems.... We might be in the 


22nd century before we get the 21st-century technology.+ 


It is rather telling that many of the people who were at the FBI when the Virtual 
Case File disaster happened aren’t there anymore. 


In 2005 the FBI announced a new program, Sentinel. This time it would work. 
This time they’d put in the right safeguards, the right budget procedures, the right 
controls. They’d learned their lesson. The price tag? A mere $451 million. And it 
would be fully operational by 2009. 


What could possibly go wrong? In March of 2010 the answer landed on Jeft 
Johnson’s desk. Lockheed Martin, the contractor hired to make the Sentinel system, 
had already spent $405 million. They’d developed only half of the project, and it was 
already a year late. An independent analysis estimated it would take another six to 
eight years to finish the project, and the taxpayers would have to throw in at least 
another $350 million. 


Finding some way around that was Johnson’s problem. 


What went wrong and how the situation got fixed are why I’m writing this book. 
It wasn’t that these weren’t smart people. It wasn’t that the Bureau didn’t have the 
right personnel in place, or even the right technology. It wasn’t about a work ethic or 
the right supply of competitive juices. 


It was because of the way people were working. The way most people work. The 
way we all think work has to be done, because that’s the way we were taught to do it. 


When you hear what happened, it sounds at first as if 1t makes sense: the people 
at Lockheed sat down before they bid on the contract, looked at the requirements, and 
started planning how to build a system that would do all that. They had lots of 
intelligent people working for months, figuring out what needed to be done. Then they 
spent more months planning how to do it. They produced beautiful charts with 
everything that needed to be accomplished and the time it would take to complete each 
and every task. Then, with careful color selection, they showed each piece of the 
project cascading down to the next like a waterfall. 
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These charts are called Gantt charts, after Henry Gantt, who developed them. 
With the advent of personal computers in the 1980s making it easy to create these 
intricate charts—and to make them really complex—they have become works of art. 
Every single step in a project is laid out in detail. Every milestone. Every delivery 
date. These charts truly are impressive to behold. The only problem with them is that 
they are always, always wrong. 


Henry Gantt invented his famous charts around 1910. They were first used in 
World War I by General William Crozier, who was the Chief of Ordnance for the US 
Army. Anyone who has studied that war knows that efficient organizational capability 
was not exactly a salient feature. Why a World War I artifact has become the de facto 
tool used in twenty-first-century project management has never been quite clear to me. 
We gave up on trench warfare, but somehow the ideas that organized it are still 


popular. 


It’s just so tempting: all the work needed to be done on a massive project laid out 
for everyone to see. I’ve visited many companies that have people whose only job 1s 
to update that Gantt chart every day. The trouble is, once that beautifully elegant plan 
meets reality, it falls apart. But instead of scrapping the plan, or the way they think 
about the plan, managers instead hire people to make it look as if the plan is working. 
Essentially, they’re paying people to lie to them. 


This unfortunate pattern echoes those reports the Soviet politburo was getting in 
the 1980s just before the total collapse of the USSR. A complete mirage. Now as then, 
the reports become more important than the reality they’ re supposed to describe, and if 
there’s a discrepancy, reality is the problem, not the charts. 


When I was a West Point cadet, I slept in Dwight Eisenhower’s old room. At 
night, the streetlights would reflect off a gold plate on the mantelpiece and sometimes 
wake me up. dwight d. eisenhower slept here, the plate read. And I’d remember that 
Eisenhower once observed that planning for combat is important, but as soon as the 
first shot is fired, your plans go up in smoke. At least he had enough sense not to use a 
Gantt chart. 


So Lockheed presented the FBI with all these lovely charts, and the Bureau 
signed on. Supposedly, the task was now so well planned out that nothing could go 
wrong. “Look, it’s in the color-coded, time-stamped, bar-graphed plan.” 


Yet when Jeff and his boss, CIO Chief Chad Fulgham, looked at the plan in the 
spring of 2010, they knew it for what it was, what such charts a// are, really: a 
complete fabrication. When the two men started to look at actual development and 
actual deliverables, they realized the problem was beyond fixing. New defects in the 
software were being discovered faster than old ones were being fixed. 


Chad told the Department of Justice Inspector General that they could complete 
the Sentinel project by bringing development in-house, cutting the number of 
developers, and that, by doing so, they’d deliver the most challenging half of the 
project in less than a fifth of the time with less than a tenth of the amount budgeted. The 
skepticism in the usually dry IG reports to Congress is palpable. In the October 2010 
report, after laying out their nine points of concern with the proposal, the IG 
watchdogs conclude: “In sum, we have significant concerns and questions about the 
ability of this new approach to complete the Sentinel project within budget, in a timely 
fashion, and with similar functionality....”2 


A New Way of Thinking 


This new approach is called “Scrum.” I created it twenty years ago. Now it is the only 


way proven to help projects like these. There are two ways of doing things: the old 
“Waterfall” method that wastes hundreds of millions of dollars and often doesn’t 
deliver anything, or the new way, which, with fewer people and in less time, can 
deliver more stuff with higher quality at lower cost. I know it sounds too good to be 
true, but the proof is in the results. It works. 


Two decades ago I was desperate. I needed a new way of thinking about work. 
And through tons of research and experimentation and looking over past data I realized 
we all needed a new way of organizing human endeavor. None of it is rocket science; 
it’s all been talked about before. There are studies going back to World War II that lay 
out some of the better ways that people work. But for some reason people never really 
put together all the pieces. Over the past two decades I’ve tried to do just that, and 
now this methodology has become ubiquitous in the first field I applied it to, software 
development. At giants such as Google, Amazon, and Salesforce.com, and at small 
start-ups you haven’t heard of yet, this framework has radically shifted how people get 
things done. 


The reason this framework works is simple. I looked at how people actually 
work, rather than how they say they work. I looked at research done over decades and 
at best practices in companies all over the world, and I looked deeply at the best 
teams within those companies. What made them superior? What made them different? 
Why do some teams achieve greatness and others mediocrity? 


For reasons Ill get into further in future chapters, I called this framework for 
team performance “Scrum.” The term comes from the game of rugby, and it refers to 
the way a team works together to move the ball down the field. Careful alignment, 
unity of purpose, and clarity of goal come together. It’s the perfect metaphor for what I 
want teams to do. 


Traditionally, management wants two things on any project: control and 
predictability. This leads to vast numbers of documents and graphs and charts, just 
like at Lockheed. Months of effort go into planning every detail, so there will be no 
mistakes, no cost overruns, and things will be delivered on schedule. 


The problem is that the rosy scenario never actually unfolds. All that effort 
poured into planning, trying to restrict change, trying to know the unknowable is 
wasted. Every project involves discovery of problems and bursts of inspiration. 
Trying to restrict a human endeavor of any scope to color-coded charts and graphs is 
foolish and doomed to failure. It’s not how people work, and it’s not how projects 
progress. It’s not how ideas reach fruition or how great things are made. 


Instead, it leads to frustrated people not getting what they want. Projects are 
delayed, come in over budget, and, in too many cases, end in abject failure. This is 


especially true for teams involved in the creative work of crafting something new. 
Most of the time, management won’t learn of the glide path toward failure until 
millions of dollars and thousands of hours have been invested for naught. 


Scrum asks why it takes so long and so much effort to do stuff, and why we’re so 
bad at figuring out how long and how much effort things will take. The cathedral at 
Chartres took fifty-seven years to build. It’s a safe bet that at the beginning of the 
project the stonemasons looked at the bishop and said, “Twenty years, max. Probably 
be done in fifteen.” 


Scrum embraces uncertainty and creativity. It places a structure around the 
learning process, enabling teams to assess both what they’ve created and, just as 
important, how they created it. The Scrum framework harnesses how teams actually 
work and gives them the tools to self-organize and rapidly improve both speed and 
quality of work. 


At its root, Scrum is based on a simple idea: whenever you start a project, why 
not regularly check in, see if what you’re doing is heading in the right direction, and if 
it’s actually what people want? And question whether there are any ways to improve 
how you’re doing what you’re doing, any ways of doing it better and faster, and what 
might be keeping you from doing that. 


That’s what’s called an “Inspect and Adapt” cycle. Every little while, stop doing 
what you’re doing, review what you’ve done, and see if it’s still what you should be 
doing and how you might do it better. It’s a simple idea, but executing it requires 
thought, introspection, honesty, and discipline. I’m writing this book to show you how 
to do it. And not just in software companies. I’ve seen Scrum used successfully to 
build cars, run a laundry, teach students in a classroom, make rocket ships, plan a 
wedding—even, as my wife has used it, to make sure that the “honey-do” list gets 
done every weekend. 


The end results of Scrum—the design goal, if you will—are teams that 
dramatically improve their productivity. Over the past twenty years I’ve built these 
teams over and over and over again. I’ve been the CEO, CTO, or head of engineering 
of a dozen companies, from small start-ups with a few people in one room to large 
enterprises with offices spread across the planet. I’ve consulted and coached hundreds 
more. 


The results can be so dramatic that leading research and analysis firms such as 
Gartner, Forrester Research, and the Standish Group now say that the old style of 
work is obsolete. Companies that still cling to tried-but-not-true ideas of command 
and control and that attempt to impose rigid predictability are simply doomed to fail if 
their competitors use Scrum. The difference is too great. Venture capital firms like 


OpenView Venture Partners in Boston, where I’m an adviser, say that Scrum offers 
too big a competitive advantage not to use it. These are not warm and fuzzy people; 
these are gimlet-eyed money men, and they simply say, “The results are indisputable. 
Companies have two choices: change or die.” 


Fixing the FBI 


At the FBI, the first problem the Sentinel team faced was contracts. Every single 
change ended up being a contract negotiation with Lockheed Martin. So Jeff Johnson 
and Chad Fulgham spent months unraveling all the contracts, taking the development 
inside, and cutting the staff from hundreds to under fifty. The core team was even 
smaller. 


The first week they did what a lot of people in these circumstances do: they 
printed out all the requirements’ documentation. If you’ve never seen what that looks 
like on a large project, it can be hundreds and hundreds of pages. I’ve seen stacks that 
are several feet high. I’ve seen this in project after project—people cut and paste and 
throw in boilerplate, but no one actually reads all those thousands of pages. They 
can’t. That’s the point. They’ve set up a system that forces them to endorse a fantasy. 


“There were 1,100 requirements. The stack was a few inches thick,” says 
Johnson. Just thinking about those documents makes me feel for the people who had 
probably spent weeks of their lives producing those documents that had no purpose. 
The FBI and Lockheed Martin aren’t alone in this—I’ve seen this duplicated at almost 
every company I have worked with. That tall stack of futility is one of the reasons 
Scrum can be such a powerful change for people. No one should spend their lives on 
meaningless work. Not only is it not good business, it kills the soul. 


So after they had this stack, they went through and prioritized each requirement. 
Which is vitally important and trickier than it sounds. Often people simply say that 
everything is important. But what they need to ask, what the Sentinel teams asked, was, 
what will bring the most value to the project? Do those things first. In software 
development there is a rule, borne out by decades of research, that 80 percent of the 
value in any piece of software is in 20 percent of the features. Think about it: when 
was the last time you used the Visual Basic Editor function in Microsoft Word? You 
probably don’t know what Visual Basic is, let alone why you’d use it. But it’s there, 
and someone spent time implementing it, but I guarantee you, it doesn’t increase the 
value of Word by much. 


Making people prioritize by value forces them to produce that 20 percent first. 
Often by the time they’re done, they realize they don’t really need the other 80 percent, 
or that what seemed important at the outset actually isn’t. 


For the Sentinel team, the question became, “Okay, we’re doing this huge project 
that is vitally important that we’ve wasted hundreds of millions of dollars on. When 
will it be done?” After thinking on it, they promised delivery in the fall of 2011. The 
Inspector General report from the fall of 2010 is a study in disbelief: 


The FBI stated that it will employ an “agile methodology” to complete the 
development of Sentinel, using fewer employees from the FBI, Lockheed Martin, 
and the companies that have supplied the major off-the-shelf components of 
Sentinel. Overall the FBI plans to reduce the number of contract employees 
working on Sentinel from approximately 220 to 40. The FBI said that, at the same 
time, the number of FBI employees assigned to the project will also decrease 
from 30 to 12.... The FBI told us it believes it can complete Sentinel with the 
approximately $20 million remaining in the Sentinel budget and within 12 months 


of beginning this new approach.2 


The use of the phrase “agile methodology” shows just how little the IG knew 
about Scrum. The term “Agile” dates back to a 2001 conclave where I and sixteen 
other leaders in software development wrote up what has become known as the “Agile 
Manifesto.” It declared the following values: people over processes; products that 
actually work over documenting what that product is supposed to do; collaborating 
with customers over negotiating with them; and responding to change over following a 
plan. Scrum is the framework I built to put those values into practice. There is no 
methodology. 


Of course Johnson’s twelve-month promise was somewhat misleading. Because, 
in actuality, they didn’t know; they couldn’t know. The FBI didn’t know how fast their 
teams could actually work. It’s something I tell executives all the time: “Ill know 
what the date will be when I see how much the teams improve. How fast they’! get. 
How much they’ |! accelerate.” 


It was also crucial, of course, that team members figure out what would stop 
them from accelerating. As Jeff Johnson put it, “I handled impediment removal.” An 
“impediment” is an idea that comes from the company that first formed a lot of the 
ideas Scrum is based on: Toyota. And, more specifically, Taiicht Ohno’s Toyota 
Production System. 


I won’t go into all the details here, but one of the key concepts that Ohno 
introduced is the idea of “flow.” That is, production should flow swiftly and calmly 
throughout the process, and, he said, one of management’s key tasks is to identify and 
remove impediments to that flow. Everything that stands in the way is waste. Ohno 
gives waste a moral, as well as a business, value in his classic book, The Toyota 


Production System: 


It is not an exaggeration that in a low-growth period such waste 1s a crime against 
society more than a business loss. Eliminating waste must be a business’s first 
objective.4 


Ohno talks a lot about the different kinds of waste and impediments that can get in 
the way of production. For Scrum to really take off, someone in senior management 
needs to understand in his bones that impediments are nearly criminal. I'll tell you 
how to eliminate waste later on in the book. Suffice it to say here that the effect of 
eliminating waste is dramatic, but people often don’t do it, because it requires being 
honest with themselves and with others. 


Jeff Johnson knew that was his job. 


It took the Sentinel team about three months to figure out how long completing the 
project would really take. Why? This goes back to that “Inspect and Adapt’ cycle I 
talked about earlier. Scrum works by setting sequential goals that must be completed 
in a fixed length of time. In the FBI’s case, they decided on two-week cycles, with the 
understanding that, at the end of each cycle, there would be a finished increment of 
product. That meant they’d have something working, something that could be shown to 
anyone who cared to look but certainly the stakeholders and, optimally, the people 
who’d actually be using the thing. 


This methodology allows teams to get near real-time feedback on their work. Are 
they headed in the right direction? Is what they’re planning to do next really what they 
should be doing, given what they’ve discovered during that cycle? 


In Scrum we call these cycles “Sprints.” At the beginning of each cycle there is a 
meeting to plan the Sprint. The team decides how much work they think they can 
accomplish during the next two weeks. They’|I take the work items off that prioritized 
list of things that need to be done and often just write them out on sticky notes and put 
them on the wall. The team decides how many of those work items they can get done 
during this Sprint. 


At the end of the Sprint, the team comes together and shows what they ve 
accomplished during the time they’ve collaborated. They look at how many of those 
sticky notes they actually got done. Did they bring too many into the Sprint and not 
finish them all? Did they not bring enough? What’s important here is that they begin to 
have a baseline sense of how fast they can go—their velocity. 


After they’ ve shown what they’ ve done—and here’s where Ohno’s ideas come in 
—they discuss not what they did, but how they did it. They ask, “How can we work 


together better in the next Sprint? What was getting in our way during the last one? 
What are the impediments that are slowing our velocity?” You can find a more 
detailed explanation of how Scrum works in the appendix. 


And that’s why Jeff Johnson needed a few months before he could really tell how 
long the project would take. He wanted to measure the velocity of each team measured 
over a few Sprints and then see how much they could improve—how much faster they 
could go. Once he looked at how many work items each team had finished in each 
Sprint and then checked how many they had remaining until the end of the project, he 
could forecast a completion date. 


Besides learning how fast the teams were going, he also wanted to know what 
impediments were slowing them down. What he really wanted to do was accelerate 
those teams so they were producing faster—not by working longer hours (I'll go into 
why that’s a fruitless rat hole that ends up making things take longer later) but by 
working better and smarter. Jeff Johnson says his teams increased their productivity 
bya factor of three. They were going three times as fast once they got moving as 
compared to when they started. Why? They got better at working together, yes, but 
most important, they figured out the things that were slowing them down, and each 
cycle, each Sprint, they’d try to get rid of them. 


It eventually took the Sentinel project eighteen months of coding to get the 
database system deployed, and another two months to deploy it to the entire FBI. 
“Tremendous time pressure,” Johnson said when he sat down for an interview. “And 
you have to understand, the system is used for everything. Paying informants. Storing 
evidence. Case files. Calendars. This meeting is in Sentinel.” 


And the most powerful part of Scrum from his point of view? “Demos. Driving 
toward a demonstrable product on a frequent basis.” Every two weeks the Sentinel 
team would demonstrate what they’d accomplished. And this show-and-tell wasn’t 
just to themselves. They were taking what they’d achieved and running it by the people 
who would actually be using the system. Everyone who had a stake in the project sent 
someone and that could make for a pretty full house. Records. Intelligence. Special 
agents. The Office of the Inspector General. Representatives from other government 
agencies. Often enough, the Director and Deputy Director of the FBI were in the room, 
as was the acting Inspector General herself. This was not an easy crowd. 


And that was what made it work, says Johnson. “Scrum is not about the 
developers. It’s about the customers and stakeholders. Really, it was an organizational 
change. Showing the actual product was the most powerful part.” 


Actually showing the product was powerful, because people were, to put it 
mildly, skeptical of the team’s reported progress. They just couldn’t believe Sentinel’s 


progress actually kept moving at a faster and faster rate. “I was saying to Congress that 
with 5 percent of the budget and in twenty months we were going to accomplish what 
Lockheed couldn’t do with 90 percent of the budget in ten years,” says Johnson. 
“There was skepticism in the room. We had to provide reports to the Associate 
Attorney General. We would be transparent with our status, but our audience would 
assume something devious was going on. Anytime they’d seen those kinds of 
indicators in the past, the reports were less detailed, and something else was going 
on.” 


And that skepticism infected the rest of the FBI. The guys down in the basement 
are just going to screw it up again, was the thinking. This will just be one more 
temporary system that will fail, and we’ll have to go back to using paper. 


Jeff told his team about a passage he had to memorize when he was a Naval cadet 
at Annapolis. It was from Teddy Roosevelt’s speech “Citizenship in a Republic,” 
which he gave at the Sorbonne in 1910. It is oft-quoted, and you may be already 
familiar with it: 


It is not the critic who counts; not the man who points out how the strong man 
stumbles, or where the doer of deeds could have done them better. The credit 
belongs to the man who is actually in the arena, whose face is marred by dust and 
sweat and blood; who strives valiantly; who errs, who comes short again and 
again, because there is no effort without error and shortcoming; but who does 
actually strive to do the deeds; who knows great enthusiasms, the great devotions; 
who spends himself in a worthy cause; who at the best knows in the end the 
triumph of high achievement, and who at the worst, if he fails, at least fails while 
daring greatly, so that his place shall never be with those cold and timid souls 


who neither know victory nor defeat.> 


The team did have some delays as they figured out exactly how fast they could do 
things, and just how hard things were to do. Finally in July of 2012, they turned 
Sentinel on. And they had to turn it on all the way, to everybody, all at once. There 
was no way to stage it. 


“It happened from one day to the next. In a criminal case or a counterterrorism 
case, something in Los Angeles might be related to something in Chicago,” says Jeff 
Johnson. “We couldn’t allow leads to be lost. At every point we had to have a clean 
and known good state.” 


And that state had to be clean and good enough to hold up in court. The data in 
Sentinel was being used to prosecute people, and its integrity had to be beyond a 
shadow of doubt. 


Jeff was frantic and nervous that first day. He went into his office and turned on 
Sentinel. It loaded. That was a good thing. And then he tried to approve a document 
with an electronic signature—a basic everyday task that tens of thousands of FBI 
employees would have to do all the time. Up came an error message. It didn’t work. 
He started to panic, Johnson remembers, visions of disaster dancing in his head. And 
then he looked carefully at the error code and realized what it meant. He hadn’t 
inserted his ID card into the machine to verify his identity. He put in the card, clicked 
his mouse, and Sentinel was good to go. 


The effect of Sentinel on the FBI has been dramatic. The ability to communicate 
and share information has fundamentally changed what the Bureau is capable of. In 
January of 2013 an FBI field office was called in when a small-business account was 
hacked. A million dollars was transferred to another country before US banks could 
stop it. Using Sentinel, the local office coordinated with the legal attaché in the 
destination country’s embassy, who then alerted local law enforcement authorities, 
who, in turn, stopped the transfer before it hit the banking system. This all happened in 
a matter of hours, something that simply couldn’t have been done in the days of three 
paper copies and red pens. It was the difference between catching a crook and letting 
him get away with it. 


In the basement of the FBI the Sentinel team is still there, the panels removed 
from their cubicles so they can see one another. There’s a poster-size copy of the 
“Agile” principles on the wall—principles I helped write and have devoted my life to 
implementing around the world. Amazingly enough for a room without windows, a 
healthy lavender plant thrives under fluorescent lights as you enter the room. 
“Lavender” was the code name of the Sentinel prototype. The team members are still 
at their posts, making improvements and adding new functionality to the system they 
built. 


There’s an old joke in the Scrum community. A chicken and a pig are walking 
down the road, and the chicken says, “Hey, Pig, I was thinking we should open up a 
restaurant.” 


“What should we call it?” asks the pig. 
“How about ‘Ham and Eggs’?” 
“No thanks,” says the pig. “I’d be committed, but you’d only be involved!” 


The idea in Scrum is that the “pigs” are the ones who are totally committed to the 
project and are responsible for its outcome. The “chickens” are the people who are 
informed of its progress, the stakeholders. On the wall in the Sentinel room is a pig- 
shaped bell. When it rings, the people who did what everyone said couldn’t be done 
know they’re being called. There’s another bell, the doorbell, but that’s for the 


chickens. 


The world is constantly getting more complicated, and the work we do is gaining 
in complexity at an ever-increasing rate. Take cars, for example. I used to work on my 
car all the time doing basic repairs. Thirty years ago I could rebuild a radiator. Now, 
when I pop open the hood, I may as well be looking at the insides of a computer. 
Actually, that’s basically what I am doing, since a new Ford has more lines of code in 
it than Facebook and Twitter combined. Creating something that complex is a massive 
human endeavor. Whenever people are involved in a complex, creative effort, whether 
they’re trying to send a rocket to space, build a better light switch, or capture a 
criminal, traditional management methods simply break apart. 


And we know this—as individuals and as a society. We see echoes of our real 
lives captured in fictional workplace dystopias like those depicted in the cartoon 
Dilbert or the movie Office Space. We’ve all gone home and told our partners or 
friends of the madness that is modern corporate “organization.” We’ve all been told 
that filling out the form correctly is more important than doing the work, or that we 
need to have a meeting to prep for the pre-meeting meeting. It’s madness. And yet we 
keep on doing it. Even in the face of absolute and complete failure. 


The launch of Healthcare.gov, the website where Americans are supposed to be 
able to sign up for health insurance, is a great example. The front end was beautiful. It 
was clever, clear—a great design. It was completed in three months using Scrum. The 
back end, though—that was the debacle. It simply didn’t work. It was supposed to 
hook up databases in the IRS to state databases, to insurance company databases, to 
the department of Health and Human Services. This is a complex piece of work. It 
involved more than twenty contractors working on different bits and pieces, and they 
planned it all using Waterfall techniques. They only tested the site at the very end for a 
few days, rather than doing incremental testing along the way. 


The tragedy is that everyone knew better. The people who work for those 
contractors aren’t stupid; they knew better. The problem was, everyone said, “Not my 
job.” They delivered their piece and left it at that. They never looked at the site from 
the user’s point of view, merely from their own. The reason they could do that was 
that they weren’t aligned—weren’t united in a common purpose. What Scrum does is 
bring teams together to create great things, and that requires everyone not only to see 
the end goal, but to deliver incrementally toward that goal. There was no one in charge 
of the Healthcare.gov project who insisted everything be tested as it was built, and, 
unfortunately, as failures go, the site is hardly atypical. The people who fixed 
Healthcare.gov? They used Scrum. 


How many times do you hear about some massive project costing millions and 
millions being cancelled not only because of the cost overruns, but because it simply 


doesn t work? How many billions of dollars are spent each year producing nothing? 
How much of your life is wasted on work that both you and your boss realize doesn’t 
create value? You might as well be digging holes and filling them in again, for all the 
impact you’re having. 


It doesn’t have to be this way. It really doesn’t. Just because everyone has always 
told you that’s the way the world works doesn’t mean they’re right. There is a 
different way of doing things—a different way of working. 


And if youdon’t do it, you'll be outsourced. Or your company will die. The 
hypercompetitive world of twenty-first-century work has no room for waste and 
foolishness. 


A further important point: working in a maximally productive way—the Scrum 
way—doesn’t have to be confined to business. What if people used this method to 
address the big problems our species struggles with—such as dependence on oil, or 
poor education, or lack of clean water in impoverished parts of the globe, or rampant 
crime? What if there really was a better way to live and work and solve problems 
differently? A way we really could change the world? There is. There are people 
using Scrum to address each of those problems I’ve mentioned, and they’re making a 
powerful impact. 


In this book you’re going to learn some of the fundamental ways that people work 
best, why we’re awful at estimating, and why working overtime will make your 
project late. I’m going to take you through all the research and applications that people 
and scientists and organizations have diligently done for years, and how Scrum ties it 
all together in a way that you can implement tomorrow. 


I’m going to show youhow. First, though, I want to tell the story of how I got 
here. 


THE TAKEAWAY 


Planning Is Useful. Blindly Following Plans Is Stupid. It’s just so tempting 
to draw up endless charts. All the work needed to be done on a massive 
project laid out for everyone to see—but when detailed plans meet reality, 
they fall apart. Build into your working method the assumption of change, 
discovery, and new ideas. 


Inspect and Adapt. Every little while, stop doing what you’re doing, 


review what you’ve done, and see if it’s still what you should be doing and 
if you can do it better. 


Change or Die. Clinging to the old way of doing things, of command and 
control and rigid predictability, will bring only failure. In the meantime, the 
competition that is willing to change will leave you in the dust. 


Fail Fast So You Can Fix Early. Corporate culture often puts more weight 
on forms, procedures, and meetings than on visible value creation that can 
be inspected at short intervals by users. Work that does not produce real 
value is madness. Working product in short cycles allows early user 
feedback and you can immediately eliminate what is obviously wasteful 
effort. 


CHAPTER TWO 


The Origins of Scrum 


For American fighter pilots in Vietnam, a tour of duty meant flying one hundred 
missions into enemy territory. Fifty percent of the pilots got shot down. Some were 
rescued, but most never made it back. In 1967, as a young, somewhat wet-behind-the- 
ears fighter pilot, I was shipped from Mountain Home Air Force Base in Idaho to 
Udorn Royal Thai Air Force Base in Northern Thailand to do what was the most 
dangerous job in the US Air Force: reconnaissance. 


This was long before the age of Predator drone missions and reliable satellite 
imagery. My RF-4C Phantom was stripped of all weapons and equipped with cameras 
and an extra fuel tank. My job was to fly into enemy territory so that my navigator 
could take before-and-after photos of our bombing missions. Most of the missions 
were at night, and I’d race through the tropical darkness just a few hundred feet from 
the ground, almost brushing the treetops. The moment I crossed over the border into 
North Vietnam, my Heads-Up display would light up like a pinball machine, and the 
loud missile-warning system would go off with a flurry of beeps and whistles. The sky 
would brighten with tracer fire from antiaircraft guns, and I knew that, in minutes, 
missile radar would soon be pinpointing my aircraft unless 500 feet was low enough 
to stay in the ground clutter. 


During these moments my adrenaline would pump, but I never lost my cool. 
Instead, the danger almost settled me. I credit this to the training I got from the Air 
Force on how to control risk. That training taught me to do four things: Observe, 
Orient, Decide, and Act. Specifically, I would observe the target area, figure out the 
best path into the hot zone and the best path out, orient myself in the face of unexpected 
events, and then act decisively based on instincts and hardwiring. Hesitation could get 
pilots killed, but so did foolhardiness. As soon as my navigator had taken his pictures, 
I'd yank back on the stick and pull up out of the hot zone, the g-force reducing my 
vision to a pinprick. My navigator often passed out from the g-force or, 1n some cases, 
lost control of his bowels. But he never complained. Because I always got us back 
alive. 


Back then I was just a young jet pilot hoping to survive my required missions. I 
didn’t know that my flight experience, and the training I’d received on how to think 
and act in a life-or-death situation, would shape the way I would work for the rest of 
my life. I arrived in Vietnam in 1967 with two squadrons of F-4 fighters and two RF- 
AC reconnaissance aircraft, one hundred planes in total. The aircraft replaced two 
squadrons of RF-101s. Of those fifty RF-101s, all but four had been shot down in one 
year. The four remaining had so many bullet holes, they were unflyable. I’m not sure 


how their pilots landed them after their last mission. The RF-4C was a more resilient 
fighter plane, but half of our aircraft were still shot down within a year. We’d 
improved survivability, but still 50 percent of those who showed up with me didn’t 
make it back to base. The lucky ones were rescued from the jungle before they could 
be imprisoned. 


When I returned from the Vietnam war, I pursued a Master’s degree from 
Stanford in statistics and spent as much time as possible at the Stanford Artificial 
Intelligence Laboratory. From there I became a professor of mathematics at the Air 
Force Academy, where I embarked on a PhD program in biometrics at the University 
of Colorado Medical School. There I asked my adviser, Dr. John Bailar, one of the 
most distinguished researchers in medicine and statistics, how I could do a thesis that 
would be useful and not wind up on a dusty shelf in the library. He handed me three 
hundred medical-journal papers on cancer. Each had graphs showing cancer statistics, 
which varied wildly for humans and animals and tumor types. Bailar said that if I 
could explain why they were all different, he’d award me a doctoral degree. So that’s 
what I did, and I got that degree. 


How I did it was by spending years trying to figure out what happens in a cell to 
turn it cancerous. I learned a lot about systems theory and how a system only has 
certain stable states. As a cell evolves, it moves from one stable state to another. 
Figuring out the rules to move a complex adaptive system from one state to another, 
and how to make the next state a positive one rather than a negative one, was 
something I spent nearly a decade on. 


Years later it occurred to me that organizations, teams, and people are all 
complex adaptive systems. The same things that move cells from one state to another 
are also what move people from one state to another. To change a cell, you first inject 
energy into the system. At first there’s chaos, there seem to be no rules, everything is 
in flux. When you do this to organizations trying to change, people often freak out. 
They can’t understand what’s happening. They don’t know what to do. But remarkably 
quickly, just like a cell, an organization settles into a new steady state. The only 
question is whether the new state is better than the old one. Is the cell cancerous or 
healthy? How, I wondered, can we figure out some simple rules that will guide teams 
to settle into a more productive, happier, supportive, fun, and ecstatic state? I spent 
the next fifteen years trying to figure that out. 


During the Reagan administration, the government radically cut grants for 
scientific research, including my National Cancer Centers research grant, where I was 
Principal Investigator of data collection and analysis for Colorado Regional Cancer 
Center clinical trials and epidemiology studies. As I was figuring out what to do, a 
company called MidContinent Computer Services contacted me because they heard I 


was the leading expert in the area of their newest technology. MidContinent was in the 
business of servicing 150 banks across North America. Their hottest new product was 
what they called an “Automatic Teller Machine” network. This was in 1983, when 
getting cash usually meant standing in line at the bank or pulling up to the bank’s drive- 
through window in your car. You’d write a check out to “cash” in the amount you 
wanted and hand it to the teller. 


ATMs were going to solve this hassle, but back then MidContinent was having 
problems getting its networks to talk to one another. They needed someone who’d 
been thinking about systems to fix this, and they made me a lucrative offer to be a vice 
president of advanced systems. Their network computers were the same machines I’d 
spent years running my doctoral programs on, so it was a good fit. 


Or so I thought. Nothing is ever easy, 1s it? When I walked into the company, I 
came upon a division doing Waterfall-method projects. There were hundreds of 
computer programmers who sat at their desks all day ostensibly working, but they 
couldn’t deliver anything on time or on budget. For the Automated Teller Machines, 
costs were 30 percent higher than revenue. The inefficiencies were mind-boggling. 


I spent some time early on trying to figure out how things worked. You can 
imagine how upper management treated my guys. There was a lot of screaming and 
micromanaging and passive-aggressive behavior and demands for harder work and 
overtime. But no matter how much management pressed, the projects were still 
chronically late, still over budget, and not delivering what they were supposed to. 


I decided the best option was for us to change everything. The operation was too 
broken to fix piecemeal, so I decided to make a company within a company. I asked 
our CEO, Ron Harris, to let me form a separate organization with everyone who was 
involved in the ATM networks. We’d have our own sales team, our own marketing 
team, and our own finance people. Ron was a brilliant and creative CEO who trusted 
my work. Perhaps under someone else this would never have happened. After hearing 
my idea, he told me, “Sutherland, if you want that kind of headache, take it.” 


I did. I went to the developers and managers and told them, “The first thing we 
need to do is to stop doing stuff that is killing us.” It’s like that old joke about banging 
your head against a brick wall just so it feels good when you stop. “We’ve got to 
figure out a better way of working,” I told them, “and we have to start immediately.” 


So we ran the entire small company as one team split up into sub-teams. Bonuses 
werent based on individual performance; they were based on total company 
performance. We came up with tools that found their way into Scrum ten years later— 
for example, the concept of a Product Owner, a Product Backlog, and weekly Sprints, 
which I'll eventually get into more deeply, and which are laid out in the appendix. In 


six months, we were the most profitable division in the company. Revenue was 30 
percent higher than expenses. Our Nonstop Tandem systems were the first online 
transaction computers that banks trusted enough to use. We deployed them all over 
North America. Nowadays just about anywhere you go in the country, you can find an 
ATM machine. And all those machines know exactly how much money you have. My 
team had a lot to do with that. And, yes, you’re welcome. 


Learning to Think Like a Robot 


After my first career in the military and my second in academia, I found myself 
something of an outsider in business. But that outsider’s perspective was one of my 
most valuable assets. From day one, it was a mystery to me why people insist on 
working in ways they Anow are inefficient and wasteful and that are dehumanizing and 
depressing. I guess they figure that’s the way everyone does it, so it must be the best 
way. 


I really enjoyed my time at MidContinent, but I was eager to test my skills on new 
challenges. For the next two decades I ended up working for companies large and 
small as VP of Engineering or Chief Technology Officer. At each, I tried to get teams 
to work together in more efficient ways. At one of those companies, I found myself in 
a building in Cambridge, Massachusetts, just a few blocks from MIT. A few PhDs and 
professors had just started a new company building robots, and they’d run out of room 
in their lab at MIT. They ended up subletting some office space from my company. 


A few weeks after they moved in, the most unexpected thing happened: a six- 
legged robot, the size of a cat, ran into my office and began chasing me around my 
desk. The roboticists came in and nervously apologized for their machine, but every 
few days it would happen again. One of the robots would escape their lab and start 
running around the building. I’d hear the mechanical clacking of legs scurrying down 
the hallways. 


On Friday afternoons I always served wine and beer at the office so that 
everyone could unwind and socialize after a hard week. I’d invite the roboticists 
down the hall to these events, and one Friday afternoon Rodney Brooks showed up. 
Brooks, a professor of artificial intelligence at MIT, was one of the founders of the 
robot company. I asked him how the roving robots worked. 


“For decades we’ve tried to make a really smart thinking machine,” he told me. 
“We spent billions of dollars, many, many years of work, building the biggest 
computers we could, with the biggest databases, but all we got was a computer that 
can beat people at chess.” 


His robots, he explained, took a completely different approach. Rather than try to 


build something with a single central brain, they built a robot in which each of the six 
legs had its own brain. A processor in the spine had a few simple rules: move 
forward, go back, don’t bump into other legs. The neural-network chip in the head of 
the robot knew these rules and acted as referee for all the parts. It told the legs what it 
was seeing through its camera when it hit an obstacle—that kind of thing. 


What’s interesting, Brooks said, is that each time you turn on the robot, it learns 
to walk for the first time. There is no database of where everything is in the room. 
Instead, the world is its database. It figures everything out for the first time each time it 
is switched on. It bumps into things and figures things out based on the actual 
surroundings, which means it can adapt to any environment. 


“Let me show you,” he said as he took me over to their lab. He popped a blank 
neural chip into one of the insectoid robots, and I watched it wobble to life. Hesitantly 
at first, it stumbled around the room like a fawn picking itself up on its legs for the 
first time. With each step it became more and more assured. The legs quickly learned 
to collaborate and work together. Within a few minutes the robot was racing around 
the room. Nothing was stored or programmed about how to walk; instead, a few 
simple rules kept these components working together. These legs didn’t think; they just 
did. I was blown away by the ingenuity and simplicity of the system. Here was 
something that was doing exactly what I was trained to do flying in Vietnam: Observe, 
Orient, Decide, and Act. It was taking in its environment and behaving decisively 
based on the data from that environment. 


“What would happen,” I asked Brooks, “if we could come up with a simple 
instruction set for teams of people to work together just like those legs? They would 
self-organize and self-optimize, just like that robot.” 


“T don’t know,” he replied. “Why don’t you try it and let me know how it works 
out?” 


Don’t Go Chasing Waterfalls 


More and more I realized that, if I could create a system that, like that robot, could 
coordinate independent thinkers with constant feedback about their environment, much 
higher levels of performance would be achieved. By streamlining the flow of 
information among “legs” of a group, we could achieve efficiencies that had never 
been reached before. 


My conversation with Rodney Brooks took place more than two decades ago. For 
many years he was the head of robotics and artificial intelligence at MIT, and that 
spidery robot I met, dubbed “Genghis Khan,” now sits in the Smithsonian as a 
collector’s item. By now you’re probably familiar with one of Brooks’s companies, 


iRobot, which makes the Roomba vacuum cleaner and uses the same adaptive 
intelligence to clean your floors that Genghis Khan used to chase me around my office. 
His latest innovation at Rethink Robotics, the Baxter robot, can work collaboratively 
with humans in a common workspace. 


I was inspired by Brooks’s work. And in 1993 I took those ideas with me to a 
company called Easel, where I was hired as VP of Object Technology. The executives 
at Easel wanted my team to develop a completely new product line in six months that 
would be aimed at some of their biggest customers—such as the Ford Motor 
Company, which used their software to design and build internal applications. I sat 
down with my development team and told them I knew they couldn’t do it using the 
same old way of developing software. 


That old methodology was the Waterfall method I described in the last chapter: 
everything related to a project carefully laid out on those massive Gantt charts, every 
task measured out precisely in hours highlighted in pretty colors flowing down the 
page like a waterfall. Those charts were beautiful in their precision. They were also 
complete fabrications. 


At Easel, I knew the Waterfall methodology would put us months if not years past 
our deadline. We had to come up with a completely different way of doing things. I 
went to the CEO and told him we were scrapping the Gantt chart. He was shocked and 
demanded to know why. 


“How many Gantt charts have you seen in your career?” I asked. 
“Hundreds,” he replied. 

“How many of them were right?” 

He paused. “None.” 


That’s when I told him I was going to give him working software at the end of the 
month instead of a broken Gantt chart. He could try it out for himself and see if we 
were on track. We had to try it, if we were going to meet our deadline. 


My team and I spent a few weeks reading hundreds of papers and books and 
articles on the organization of teams and product development. Then one day, one of 
the developers came in with a Harvard Business Review paper from 1986, written by 
two Japanese business professors, Hirotaka Takeuchi and Ikujiro Nonaka. It was 
titled, “The New New Product Development Game.” Takeuchi and Nonaka had 
looked at teams from some of the world’s most productive and innovative companies: 
Honda, Fuji-Xerox, 3M, Hewlett-Packard, and others. They argued that the old way of 
doing product development, typified by NASA’s Phased Program Planning system—a 
Waterfall system—was fundamentally flawed. Instead, the best companies used an 


overlapping development process that was faster and more flexible. The teams were 
cross-functional. The teams had autonomy. They were empowered to make their own 
decisions. And they had a transcendent purpose. They were reaching for something 
bigger than themselves. Management didn’t dictate. Instead, executives were servant- 
leaders and facilitators focused on getting obstacles out of their teams’ way rather than 
telling them what and how to do product development. The Japanese professors 
compared the teams’ work to that of a rugby team and said the best teams acted as 
though they were ina scrum: “... the ball gets passed within the team as it moves as a 
unit up the field.” 


Takeuchi and Nonaka’s paper made a splash when it was first published, but that 
was seven years before we were reading the paper at Easel. Everyone had admired it, 
but no one had done anything with it. The average American manager was unable to 
make sense of it even though Toyota was rapidly increasing market share using this 
approach. At Easel we had nothing to lose. We decided to try it, even though the paper 
focused on manufacturing, not software development. I thought their ideas tapped into 
something fundamental, a descriptive process of how humans work together best in 
any endeavor. It flowed into all the other experiments I’d conducted, going back to my 
first job in the private sector at MidContinent. 


This was the formal birth of “Scrum.” We delivered the product at Easel on 
schedule within six months, under budget, and with fewer bugs than any previous 
delivery. 


I got so excited about the possibilities of this new form of project management 
that all my future work focused on refining Scrum for companies. In 1995 I presented a 
paper with Ken Schwaber, called “SCRUM Development Process,” which codified 
those practices at an Association for Computing Machinery research conference. Since 
then we have dropped the all-caps and tweaked the idea a little bit, but the 
fundamental principles are the same—and those companies that embrace the process 
typically see immediate benefits. 


Inspect and Adapt 


Scrum teams that work well are able to achieve what we call “hyperproductivity.” It’s 
hard to believe, but we regularly see somewhere between a 300- to 400-percent 
improvement in productivity among groups that implement Scrum well. The best teams 
can achieve productivity increases of up to 800 percent and replicate that success over 
and over again. They also end up more than doubling the quality of their work. 


So how do you build autonomy, transcendence, and cross-fertilization into a 
Scrum team and from that combination achieve hyperproductivity? Well, that’s what 


the rest of this book is about, but ’'m going to lay out the basic structure here. You can 
also see it laid out in short form in the appendix. 


Since Scrum comes out of techniques used in Japanese manufacturing, it pays to 
learn a bit about where the Japanese learned them. Ironically, they learned many from 
an American: W. Edwards Deming. Deming worked for General Douglas MacArthur 
during the American occupation of Japan after World War II. MacArthur’s approach 
to rebuilding the economy was to fire most of the senior management in Japanese 
companies, promote line managers from the ranks, and bring in business operations 
experts like Deming from the United States. Deming’s influence on Japanese 
manufacturing was dramatic. He trained hundreds of engineers in what is called 
“statistical process control.” The basic idea is to measure exactly what is being done, 
and how well, and to strive for “continuous improvement.” Don’t just get better once; 
get better constantly. Always be looking for something to improve. Never, ever settle 
for where you are. How you get there is to be constantly creating experiments to see if 
you can achieve improvement. If I try this method, is it better? How about this one? 
What if I change just this one thing? 


Deming famously gave a talk to Japanese business leaders in 1950. In the 
audience were people like Akio Morita, the founder of Sony. In that talk Deming told 
them: 


... no matter how excellent your technicians, you who are leaders must strive for 
advances in the improvement of product quality and uniformity if your technicians 
are to be able to make improvements. The first step, therefore, belongs with 
management. First, your company technicians and your factories must know that 
you have a fervor for advancing product quality and uniformity and a sense of 
responsibility for product quality. 

Nothing will come of this if you only speak about it. Action is important.2 


And the method to take action, and perhaps what Deming is most famous for, is 
the PDCA cycle (Plan, Do, Check, Act). You can apply this cycle to the production of 
just about anything, be it a car, a videogame, or, heck, even a paper airplane. 


When I train people how to do Scrum, that’s what I use: paper airplanes. I divide 
people up into teams and tell them that the goal is to build as many paper airplanes as 
they can that will fly across the room. There are going to be three roles on the team. 
One person will check how many planes are built that can actually fly. Another will 
work as part of the assembly process but will also pay attention to the process itself 
and look for ways that the team can make better planes and speed up their production. 
Everyone else will concentrate on building as many planes that can actually fly the 


distance in the assembly time allowed. 


I then say we’re going to do three six-minute cycles of paper-airplane building. 
The teams have one minute each cycle to Plan how they’re going to build the airplane, 
three minutes to Do—to build and test as many airplanes as they can that can actually 
fly. And finally they'll have two minutes to Check. In this phase the team looks for 
how they could improve their paper airplane—building process. What went right? What 
went wrong? Should the design be changed? How can the construction process be 
improved? And then they will Act. In Deming’s world “to act” means to change your 
way of working based on real results and real environmental input. It’s the same 
strategy used by Brooks’s robot. 


Go through this cycle three times, and whether you’re making paper airplanes or 
actual spaceships you'll get better—significantly better (on the order of two to three 
times faster with at least double the quality). This PDCA cycle, a radical idea when 
Deming pitched it to the Japanese, is how Toyota became the number one car company 
in the world. And it’s how any sort of “Lean” manufacturing (the American term for 
using the concepts of the Toyota Production System), or Scrum product development, 
is done. 


Change or Die 


Part of the reason a new way of doing things was so imperative, and why such a broad 
swath of companies have adopted it, 1s because the state of software development was 
so bad. Projects were almost always late, over budget, and often simply didn’t work. 
And that wasn’t because people were stupid or greedy—rather, it had to do with the 
way they thought about their work. They insisted on the Waterfall method, insisted that 
everything could be planned ahead of time, even insisted that things wouldn t change 
over the course of a multiyear project. That’s just insane on the face of it. 


I learned this firsthand at BellSouth, when I visited them as a consultant years 
ago. They had top-notch engineers, many from the famous Bell Labs. They executed 
Waterfall perfectly. They'd bid on huge $10- to $20-million projects. They’d gather 
all the requirements from the customer, then go away for eighteen months and deliver 
on time and on budget exactly what the customer had asked for. They were one of the 
very, very few companies in the entire world that could pull that off. The problem 
was, at that point the customer no longer wanted what they’d said they wanted. 
Circumstances had changed. Business cycles were getting shorter, and customers were 
demanding more responsive services. 


I was brought in to see if I could help BellSouth figure out what they were doing 
wrong. I soon realized it was the entire way they were working. This can be tough to 
hear when it seems as if you’re doing everything right. So one day I stood before a 


roomful of 150 BellSouth engineers and told them that unless they changed to a 
different, more customer-responsive model, they wouldn’t last as a going concern. The 
crowd was tough. They were all really smart men and women, but they believed my 
ideas were just another management fad. I couldn’t get through to them, so I just 
shrugged and left them with a final warning: “Change or die.” As you may have 
noticed, BellSouth isn’t around anymore. 


Shu Ha Ri 


Scrum has its rootsin Japanese thought and practice. When I travelled to Japan 
recently to meet with Professor Ikujiro Nonaka, he made it clear to me that in Japan 
Scrum isn’t seen as the latest work fad. They regard it as a way of doing, a way of 
being, a way of life. When I teach people how to do Scrum, I often talk about my own 
personal experience studying the Japanese martial art of aikido over the years. 


Scrum, like aikido, or, heck, like the tango, is something that you can only really 
learn by doing. Your body and your mind and your spirit become aligned through 
constant practice and improvement. In the martial arts you learn a concept called Shu 
Ha Ri, which points to different levels of mastery. In the Shu state you know all the 
rules and the forms. You repeat them, like the steps in a dance, so your body absorbs 
them. You don’t deviate at all. 


In the Ha state, once you’ve mastered the forms, you can make innovations. Put an 
extra swing in your step down the dance floor. 


In the Ri state you’re able to discard the forms, you’ve truly mastered the 
practice, and you’re able to be creative in an unhindered way, because the knowledge 
of the meaning of aikido or the tango is so deeply embedded in you, your every step 
expresses its essence. 


Scrum is a lot like that. It requires practice and attention, but also a continuous 
effort to reach a new state—a state where things just flow and happen. If you’ve ever 
watched great dancers or gymnasts, you know that their motion can almost seem 
effortless, as if they’re doing nothing but simply being. They seem as if they couldn’t 
be anything else but what they are in that moment. I experienced that one day when a 
diminutive aikido master threw me effortlessly through the air, and yet did so ina way 
that caused me to fall gently to the mat, as though I were a baby being gently placed in 
a cradle. 


That’s what you want to get to with Scrum. That’s the state I want everyone to get 
to in their lives. Work doesn’t have to suck. It can flow; it can be an expression of joy, 
an alignment toward a higher purpose. We can be better. We can be great! We just 
have to practice. 


For the rest of this book I’m going to spend each chapter focusing on one 
particular aspect of Scrum. These deep dives are meant to give you the reasoning 
behind the concepts and why Scrum is structured the way it is. You can find 
“Implementing Scrum” (a definitive description of Scrum) in the appendix, but it just 
tells you what to do. If you’ Il come along with me, [ll tell you why. 


THE TAKEAWAY 


Hesitation Is Death. Observe, Orient, Decide, Act. Know where you are, 
assess your options, make a decision, and act! 


Look Outward for Answers. Complex adaptive systems follow a few 
simple rules, which they learn from their environment. 


Great Teams Are. They are _ cross-functional, autonomous, and 
empowered, with a transcendent purpose. 


Don’t Guess. Plan, Do, Check, Act. Plan what you’re going to do. Do it. 
Check whether it did what you wanted. Act on that and change how you’re 
doing things. Repeat in regular cycles, and, by doing so, achieve continuous 
improvement. 


Shu Ha Ri. First, learn the rules and the forms, and once you’ve mastered 
them, make innovations. Finally, ina heightened state of mastery, discard the 
forms and just be—with all the learning internalized and decisions made 
almost unconsciously. 


CHAPTER THREE 


Teams 


Teams are what get things done in the world of work. There are teams that make cars, 
answer phones, do surgery, program computers, put the news on, and burst through the 
doors of apartments occupied by terrorists. Certainly, there are artisans or artists who 
do work by themselves, but teams are what make the world go ’round. And they’re 
what Scrum is based on. 


Everyone knows this, but in business we all too often focus solely on individuals, 
even if production is a team effort. Think of performance bonuses or promotions or 
hiring. Everything is focused on the individual actor, rather than the team. And that, it 
turns out, is a big mistake. 


Managers tend to focus on the individual because it makes intuitive sense. You 
want the best people, and people are different, so focus on getting the best performers, 
and you'll get better results, right? Well, it’s not quite that simple. 


Take, for example, the process by which students receive grades in a class. At 
Yale University a computer-programming course taught by Professor Stanley 
Eisenstat, CS 323, is notoriously hard. When students began complaining about how 
long each assignment took, the professor didn’t make his assignments easier, but he 
did start tracking how long each student needed to complete them. Then Joel Spolsky, 
who was in Eisenstat’s course back in the 1980s and now has his own software 
business, compared that data to the actual grades people were getting. He wanted to 
know if there was any correlation between the time spent on a project and the grade 
the student received. Interestingly, there isn’t. Some people work quickly and get an 
A, and some people work meticulously and get the same grade. The only difference is 
the amount of time spent. So what is the application for business? 


Well, if you’re a manager, it seems that you want to hire not just the workers who 
earn A’s, but those who earn them in the shortest amount of time. In the Yale study, the 
fastest students outpaced their slow compatriots by a ratio of 10:1. They were ten 
times faster, and they got just as good a grade. Ten times faster is pretty dramatic, 
right? So it seems that companies should focus on hiring the quickest people and 
weeding out the slow-footed. That sounds like the best approach to increasing 
productivity, but other factors can be even more crucial. 


If you look at teams instead of individuals, you see something interesting. There 
are studies that looked at some 3,800 different projects, ranging from work done at 
accounting firms to software development for battleships to tech projects at IBM. The 
analysts didn’t look at individual performance data, but rather team performance data. 


And when you examine how the teams did, you see something surprising. If the best 
team could perform a task in one week, how long do you think it took the worst team? 
You might guess the same ratio as was observed at Yale—10:1 (that is, the slow team 
took more than two months to accomplish what the fast team knocked off in a week). 
The actual answer, though, is that there is a much larger difference in team 
performance than there is in individual performance. It actually didn’t take the slow 
team ten weeks to do what the best team could do in one week. Rather, it took them 
two thousand weeks. That’s how great the difference is between the best and the 
worst. So where should you focus your attention? At the level of the individual, where 
you might be able to get an improvement of ten times if you can magically make all 
your employees geniuses? Or at the team level, boosting productivity by an enormous 
magnitude even if you merely make your worst teams mediocre? Of course, aiming for 
mediocrity will get you just that. But what if you could make all your teams great? 


At certain times in certain places with certain small groups of people, everything 
becomes possible. Even if you’ve never been on a team like that, you’ve seen them in 
action. You hear stories about them; legends are told about what they can do. I grew 
up near Boston and live there now, so some of the great teams that come to my mind 
are the Celtics of the 1980s or the New England Patriots of the Tom Brady era. When 
those teams were on, it seemed as if they were playing a different game than everyone 
else. Drives and plays that had once seemed undoable suddenly became part of the 
game plan. It was as if a state of grace had descended upon those players, and for a 
moment they could do no wrong. Larry Bird would drive down the court and pass the 
ball without looking toward what seemed to be empty hardwood. But just as the ball 
was headed out of bounds, Kevin McHale would simply appear exactly where he was 
supposed to be. And then he’d throw the ball to the side—again, seemingly without 
looking—and Robert Parish would just happen to be perfectly positioned for a shot. 
That absolute alignment of purpose and trust is something that creates greatness. 


We’ ve all seen those teams. Some of us have been lucky to be on one—or more 
than one—over the course of our lives. When I was designing Scrum, I looked at what 
super-performing teams had that other teams didn’t. Why is it, I wondered, that some 
teams change the world, and others are mired in mediocrity? What are the common 
elements that truly great teams have? And, most important, can we reproduce them? 


The answer, it turns out, 1s yes. 


In their original paper that described what became Scrum, “The New New 
Product Development Game,” Professors Takeuchi and Nonaka described the 
characteristics of the teams they saw at the best companies in the world: 


1. Transcendent: They have a sense of purpose beyond the ordinary. This self- 
realized goal allows them to move beyond the ordinary into the extraordinary. In 
a very real way the very decision to not be average, but to be great, changes the 
way they view themselves, and what they’re capable of. 


2. Autonomous: The teams are self-organizing and self-managing, they have the 
power to make their own decisions about how they do their jobs, and are 
empowered to make those decisions stick. 


3 . Cross-Functional: The teams have all the skills needed to complete the 
project. Planning, design, production, sales, distribution. And those skills feed 
and reinforce each other. As one team member that designed a revolutionary new 
camera for Canon described it: “When all the team members are located in one 
large room, someone’s information becomes yours, without even trying. You then 
start thinking in terms of what’s best or second best for the group at large and not 
only where you stand.”! 


So how do you create a team that aims for a higher goal, organizes itself, and 
constantly feeds off each member’s skills? I spent a lot of time pondering that. After 
all, you can’t just yell at people to be more self-organized and transcendent; the 
motivation has to come from within. Imposing it will kill what you’re trying to do. 
Might there be a simple set of rules that encourage the formation of magic? 


The Long Gray Line 


I thought back to when I was part of one of those magical teams. It was in the early 
1960s, when I was a cadet at the United States Military Academy, more commonly 
known as West Point. During my last year there I was appointed as training officer to 
my cadet company, L2, the “Loose Deuce.” 


In 1963, there were twenty-four companies at West Point. Al through M1 and A2 
through M2. Three times a week these companies took to the parade field and marched 
in full dress uniform, with rifles held thus and swords so, and white straps here, and 
gear placed carefully there. These parade formations have been a competition at the 
Academy for almost two hundred years. In 1963, the Loose Deuce had been at the 
bottom of those rankings for more than a century. 


The training officer has no direct power. He isn’t part of the command structure 
of the company. No one answers to him. No one has to do what he says. But after each 
parade the training officers get together and rate each company according to various 
criteria. As training officer of the Loose Deuce, I decided that what I could do was 
make things more transparent. I made colored charts of what went right and what went 
wrong and posted them in the barracks where everyone in my company would have to 


see them every day. 


At first the criticisms were simple. Charlie had his sword stuck in the dirt. Jim 
didn't turn in sync with everyone else. Dave’s salute was sloppy. There were no 
punishments or blame; it was simply facts laid out by all the other training officers that 
were brought up during evaluations. Yet these were the reasons L2 was rated at the 
bottom. 


Within just a few weeks the cadets sharpened their game, and the low ratings 
now pointed to the company commander. His orders weren’t clear enough; the timing 
wasn’t crisp enough. Not surprisingly, I got heat for criticizing the commander, but I 
said simply in response, “The ratings are the ratings. I’m just showing you what they 
are. The ranks have pulled their shit together. You are now the problem. Do you want 
to fix it? Or do you want to suck forever?” A few weeks later L2 was the number one 
company at West Point. 


The most honored cadet in West Point’s history was General Douglas 
MacArthur. He had the highest ranking of any cadet who graduated there, and he was a 
leading officer in both World Wars. As a five-star general and Medal of Honor 
winner, he had a special connection to the Corps of Cadets. 


The year before I was training my company, in May of 1962, he gave his final 
speech at West Point. You have to picture the scene properly to get the full impact. 
There were three thousand men in cadet gray uniforms sitting in this gargantuan stone 
hall with vast columns and giant chandeliers hanging from the high ceiling. About 
thirty feet up on one wall was a platform that overlooked the hall. General MacArthur, 
then frail, stood on that platform and gave what today is referred to as the “Long Gray 
Line” speech (gray being the color of the cadets’ uniforms): 


You are the leaven which binds together the entire fabric of our national system 
of defense. From your ranks come the great captains who hold the Nation’s 
destiny in their hands the moment the war tocsin sounds. 

The long gray line has never failed us. Were you to do so, a million ghosts 
in olive drab, in brown khaki, in blue and gray, would rise from their white 


crosses, thundering those magic words: Duty, Honor, Country.2 


At that, I remember, it felt as if a legion of those ghosts rose up behind 
MacArthur as he left the Corps with his final charge. And three thousand men, trained 
for war, to whom tears did not come easily, began to cry. 


In my dreams | hear again the crash of guns, the rattle of musketry, the strange, 


mournful mutter of the battlefield. But in the evening of my memory I come back 
to West Point. Always there echoes and re-echoes: Duty, Honor, Country. 

Today marks my final roll call with you. But I want you to know that when I 
cross the river, my last conscious thoughts will be of the Corps, and the Corps, 


and the Corps.2 


To this day, every cadet at the Academy has to memorize that speech, line by 
line, word for word, before they can graduate. That speech has become the spiritual 
guide for the cadet corps, and for the US officer corps at large: Duty, Honor, Country. 


Almost a year after that speech General MacArthur died. One company was 
selected to march at his funeral. To the slow, rhythmic sound of the drums, the Loose 
Deuce, the same company that had been the worst in the Corps for more than a hundred 
years, marched behind the caisson carrying the casket of one of America’s greatest 
generals. 


A few months after that funeral I marched with the Loose Deuce for the last time 
at my graduation. All twenty-four companies marched, but L2, because of our position 
in the alphabet, marched twenty-third. After the ceremony my future father-in-law 
asked me, “That company. The second to last one. They were different than all the 
rest. The others were marching; they seemed to be floating. Who were they?” 


“That was my company,” I told him. “Those men buried General MacArthur.” 
My company had achieved transcendence. 


Scrum in the Time of Revolt 


Often when people talk about great teams, they only talk about that transcendent sense 
of purpose. But while that’s a critical element, it’s only one leg of the three-legged 
stool. Just as critical, but perhaps less celebrated, is the freedom to do your job in the 
way that you think best—to have autonomy. On all great teams, it’s left to the members 
to decide how to carry out the goals set by those leading the organization. 


Tahrir Square has become synonymous with the Egyptian revolution and the 
ongoing struggles in that country, but before January of 2011 it was just another dirty, 
traffic-clogged rotary in downtown Cairo. To the north lies the rose-red Egyptian 
Museum and to the south the high walls of the American University in Cairo and the 
iconic Muqawama government building. The headquarters of the National Democratic 
Party of the Egyptian dictator Hosni Mubarak was on the west, as was the Arab 
League headquarters. Oddly, at the square’s eastern edge was, of all things, a KFC, 
which soon became the backdrop to stone-throwing protestors pushing back police. 


In late January of 2011 a small group of protesters decided to demonstrate within 


the traffic circle to protest the brutal killing of a young man named Khaled Said by 
Egyptian police. What might have been another small protest against a repressive 
regime caught fire, ignited the Egyptian imagination, and eventually drew millions to 
the square. Over the next month the unthinkable happened. Just by people gathering and 
saying no, one of the oldest and most powerful dictatorial regimes in the Middle East 
fell. The people gathered day after day, night after night, filling the square and creating 
an alternate country where the dictator Hosni Mubarak did not rule and individuals 
could actually speak their minds. They changed their world. 


For journalists it was a massive story of historical significance. Among those 
descending on Cairo was National Public Radio, one of the premier journalism outfits 
in the United States. Caught flat-footed at first, producers and reporters for NPR blew 
deadlines, missed stories, and scrambled to meet the demands of executives back in 
Washington. 


J. J. Sutherland, my son, was sent to fix it. A longtime war producer and 
correspondent, he was assigned to Cairo to make the coverage work. The story was 
too big not to be on the air every single day, every single show, and every single hour. 
J.J. dropped down into a country where the airports had been closed, foreigners were 
desperately trying to flee, and the cell phone network and Internet had been shut down. 
He was the senior producer on the scene, but, much like a training officer at West 
Point, an NPR producer is a facilitator and organizer—a helper or booster rather than 
a typical manager or leader. J.J.’s job was to help the team do the best work they 
could. It wasn’t to te// them what to do—tather, it was to provide them with what they 
needed. The orders from management were to tell the story and to be on the air 
multiple times a day, and the team on the ground figured out how to meet that 
challenge, deciding what stories to tell and how to tell them using the medium of 
radio. 


Oddly, it was precisely because it was so difficult to communicate with 
executives back in Washington that the team was so successful. In a very real way, 
they were on their own. With constant direct oversight by Washington being 
impossible and events happening so fast, the team had to organize themselves to get 
the work done. One of the key concepts in Scrum is that the team members decide 
themselves how they’re going to do the work. It’s management’s responsibility to set 
the strategic goals, but it’s the team’s job to decide how to reach those goals. In Cairo, 
there was no way anyone not on the ground could even keep up with what was 
happening. Almost daily the NPR team would report a series of stories for the next 
day that would be rendered instantly obsolete by rapidly unfolding events. There’d be 
a major clash in the square, a speech, a resignation, or a battle, and all the team’s 
work would be for naught. Suddenly, they’d be scrambling to get something timely on 


the air. 


They succeeded by using Scrum. Their deadlines called for them to report every 
twelve hours, on Morning Edition and All Things Considered. Each cycle J.J. would 
talk to the team and ask three very simple questions: What did you do since the last 
time we talked? What are you going to do before we talk again? And what is getting in 
your way? His asking those questions, which is one of the regular rituals of Scrum, 
forced the correspondents to talk and share with one another. And J.J.’s main job, as 
de facto Scrum Master, was to make sure that those things getting in the team’s way at 
one meeting were gone by the next. The impediment could be anything—from dealing 
with Egyptian bureaucracy to getting a secure hotel room, from finding drivers and 
translators to getting correspondents out of the custody of Egypt’s feared secret police, 
the Mukhabarat. 


How did it all work out? Well, what had begun in chaos, personal disputes, and a 
failure to deliver the news quickly became a well-oiled machine that management 
didn’t even have to manage. Instead, team members managed themselves. Over the 
next few weeks NPR’s squad in Cairo produced more coverage than anyone thought 
possible. And it was of higher quality than what the competition was offering, 
eventually winning several awards. It was a feat that wouldn’t have been 
accomplished had the team not been imbued with a sense of purpose (to tell one of the 
biggest stories of their careers) and not possessed autonomy (the ability to decide for 
themselves how to produce the many threads of that overall story). 


Now Scrum is being used all over the place at NPR, from web design, to data 
journalism, to creating new radio shows. Teams at the Chicago Tribune, New York 
Times, Washington Post, and ProPublica are all using Scrum. When deadlines are 
tight, they just need the speed. 


One Team to Get the Job Done 


The third leg of the stool for great teams is that they have all the skills necessary to get 
things done. In a classically organized structure you might have the team of planners, 
followed by the team of builders, followed by the team of testers, followed by the 
production team, followed by the shipping team. Each team along the way has to finish 
its piece of the action before the project can move to the next step. No one team by 
itself can actually get a product out the door. 


The classic example of this was NASA’s “phase-gate” process. This was how 
they ran the shuttle program and other efforts in the sixties, seventies, and eighties. It’s 
very different now, but here’s how their old process worked. First, there’s a 
discovery “phase,” where people decide what they’re going to try to accomplish— 
maybe it’s build a rocket that goes to the moon. A bunch of strategists sit ina room and 


fantasize about it. Then there’s a “gate,” where a manager or group of managers has to 
sign off on the project as worthy of pursuing. Then there’s a scoping phase, where all 
the “requirements people” decide what the thing is going to do. Then there’s another 
gate, and another set of meetings, and then these humongous documents are handed off 
to the next phase, building the business case and the project plan. Then all these plans 
are taken to another set of meetings and approvals and, after that, handed off to yet 
another phase, the development phase, where the thing is actually built. Then there’s 
another bunch of meetings and documents, and the product is handed off to a whole 
other group for the next phase, testing. Those people have never seen the product 
before, but they test it, sign off that it’s right, and then push it to another gate, or set of 
interminable meetings, with another bunch of documents that no one has read. And then 
and only then is the product passed to a sixth group of people who’! actually launch 
it. It’s exhausting just writing about it. And this is how NASA used to build things. 


At one point in the early 1980s, executives from Fuji-Xerox traveled to America 
to study how the famous space agency did things. When they implemented the same 
procedures back in Japan, they immediately saw quality drop, the failure rate go up, 
and their ability to deliver sink like a stone. They quickly abandoned the process, 
saying it was likely to produce catastrophic error. The Rogers Commission that 
examined the 1986 Challenger disaster agreed. As physicist Richard Feynman 
famously wrote in Appendix F of the Commission’s report: “It would appear that, for 
whatever purpose, be it for internal or external consumption, the management of 
NASA exaggerates the reliability of its product, to the point of fantasy.” 4 


The fact is, when you look at the best teams—like the ones that existed at Toyota 
or3M _ when Takeuchi or Nonaka wrote their paper, or the ones at Google or 
Salesforce.com or Amazon today—there isn’t this separation of roles. Each team has 
all the people on it do everything, soup to nuts. 


Nicola Dourambeis is in charge of Agile practices at Salesforce.com. She’s 
responsible for some two hundred Scrum teams at a company that is routinely on such 
lists as Fortune’s “100 Best Companies to Work For” and Forbes’s “Most Innovative 
Companies in the World.” She says she sees Scrum as their “secret sauce.” “When we 
were a Start-up,” she says, “we did a major release three or four times a year. As we 
grew and scaled up, managing projects in a typical waterfall way, that fell to once a 
year in 2005-2006. That had to change. So we introduced Scrum. Since then we’ve 
been doing releases three times a year. There aren’t that many major enterprise 
companies that can do that.” 


What she looks for in a team is diversity—of skill set, thinking, and experience. 
She wants teams that are unselfish and autonomous, but she also needs them to be 
cross-functional. Teams that can get a whole project done. 


One of her tests of whether a team is on the right path comes when she asks, say, 
a network engineer, “What team are you on?” If he or she responds by mentioning the 
product they’re working on (say automation or integration) rather than their specialty 
(such as network engineering), she nods approvingly. When a specialist identifies with 
their specialty more than with the product they’re actually making, Dourambeis knows 
she still has work to do. 


Scrum at War 


One of the most dramatic examples of a cross-functional team comes from the military. 
American Special Operations Forces (SOF) operate in just this way. A typical Army 
Special Forces “A-team”’ has twelve people: a team leader (who is a commissioned 
officer), a warrant officer, a team sergeant (who runs the team in day-to-day 
operations), an intelligence sergeant, and two each of sergeants in special forces 
weapons, demolition, medical, and communications. Each team has all the capabilities 
to carry out their mission from start to finish. And they conduct cross-training across 
each skill set. They want to make sure, for example, that if both of the medics get 
killed, the communications specialist can patch up the weapons specialist. Another 
way the Special Forces operate is that, unlike much of the “regular” military, they 
don’t separate intelligence gathering and operations planning. There are no handoffs 
from one team to another, where mistakes might be made. Special Forces don’t want 
any Challenger disasters. As a result there’s constant communication among the 
people collecting the intelligence, those planning what to do with it, and those who’ll 
be going through the door. 


During the Iraq war, Special Forces teams showed that they were exceedingly 
good at killing people. They could locate an insurgent target and wipe it out that same 
night. Between 2003 and 2007 they carried out thousands of successful missions 
aimed at disrupting the Iraqi insurgency, especially Al Qaeda in Iraq. Tactically and 
operationally, they almost always succeeded in their missions. Their cross-functional, 
highly trained teams were among the most lethal forces the world had ever seen. Yet 
despite all their skill and talent they had almost zero strategic impact. During those 
first four years of the war, attacks on American forces and Iraqi civilians increased 
almost daily. During some of the darkest days of the war there were over one hundred 
attacks a day on American forces, and even the lethality of the American Special 
Forces couldn’t stem the tide. By late 2006 and early 2007 just about every informed 
commentator saw Iraq as a lost cause. Every additional American death started to be 
seen as a futile sacrifice. 


Then in 2007 General David Petraeus led what became known as the “Surge,” 
which involved putting tens of thousands more troops into the country and having them 
live among the populace. This new strategy had a remarkable impact. One reason was 


that it got the Iraqi people to believe that the Americans were on their side, fighting the 
insurgents who were blowing up bombs in their neighborhoods and conducting ethnic 
cleansing. Another reason was that the American military, using a program called the 
“Sons of Iraq,” succeeded in bribing tens of thousands of former insurgents to come 
over to the US side. But there was a third component of the strategy—something that 
journalist Bob Woodward called as revolutionary as the invention of the tank or the 
airplane. 


This weapon wasn’t a new gizmo or unmanned drone. It was what General 
Stanley McChrystal, the commander of the Joint Special Operations Command at the 
time, called “collaborative warfare.” It involved using cross-functional teams from 
across the entire US government to target and disrupt Al Qaeda networks. As the 
Washington Post described it on September 6, 2008: 


The CIA [Central Intelligence Agency] provides intelligence analysts and spy 
craft with sensors and cameras that can track targets, vehicles or equipment for 
up to 14 hours. FBI [Federal Bureau of Investigation] forensic experts dissect 
data, from cellphone information to the “pocket litter” found on extremists. 
Treasury officials track funds flowing among extremists and from governments. 
National Security Agency staffers intercept conversations and computer data, and 
members of the National Geospatial-Intelligence Agency use high-tech equipment 
to pinpoint where suspected extremists are using phones or computers.* 


What they did was create a cross-functional team that had all the skills necessary 
to get the job done. Instead of having all these experts on separate teams rarely sharing 
information, they all worked together, in the same room, sharing all their intelligence 
and planning to track down and kill Al Qaeda operatives. 


Before this, an intelligence organization would designate the target, then hand off 
the actual operations to a Special Forces team. Then that team would hand over any 
intelligence it gathered to yet another team for analysis. Those practicing the handoff 
model discovered what Fuji-Xerox discovered decades earlier when the Japanese 
tried to implement NASA’s phase-gate system, and it’s one of the main reasons Scrum 
was developed in the first place. Whenever there are handoffs between teams, there is 
the opportunity for disaster. As an article titled “Employing ISR: SOF Best Practices” 
in Joint Force Quarterly put tt: 


The interagency teams made it possible to eliminate the organizational seams 
between the different coalition actors in Iraq, placing an “unblinking eye” on 
high-value targets.... Passing responsibilities between units and organizations 


represented an “organizational blink” during which momentum slowed and the 
target might escape.® 


Sharing information and resources like this isn’t easy in any setting. ve seen 
managers almost seize up as their resources are assigned to a team outside their direct 
control. Giving up day-to-day micromanaging and control is hard to do, but to do it in 
the secretive world of intelligence and special operations is even more difficult—so 
difficult that, despite their effectiveness, the teams in Iraq were quickly disbanded 
after the Surge was deemed a success. Christopher Lamb and Evan Munsing wrote a 
fascinating article, “Secret Weapon: High-value Target Teams as an Organizational 
Innovation,” laying this out. 


. as soon as the near-failure in Iraq was averted, bureaucratic support for 
interagency teams began to decline. By 2008, other departments and agencies, 
particularly one unidentified intelligence agency, began pulling back people and 
cooperation, believing information-sharing and collaboration had gone too far.“ 


The most powerful weapon in America’s arsenal, what Bob Woodward called as 
important as the invention of the tank or the airplane, was set aside because of 
parochial departmental concerns and the worries of middle managers who were 
concerned for their careers. I’ve seen this happen at one large financial institution in 
Boston repeatedly. They'll call me up in a panic when they have a mission-critical 
project that is in trouble. They’ll have me train dozens of their people in Scrum, have 
me start up teams that are capable of addressing their emergency. They direct people 
from across the organization into cross-functional teams to address the issue. And then 
they solve it. Once the crisis is past, they disband the teams to their respective silos 
and managerial fiefdoms. The transparency and sharing of a truly fantastic team 
threatens structures rooted in secrets and obfuscation. Managers often don’t want other 
managers, their own teams, or other people within the power structure to know exactly 
what they’re doing or what is being accomplished and how fast. They see keeping that 
knowledge secret as critical to their power. Instead of being aligned with the interests 
of the greater good, they’re aligned with their own motivations, which often boil down 
to greed and ambition. It’s the same kind of thinking that led to the massive 
management failure that caused the most recent economic collapse. At many 
companies, actions were based solely on what was in it for the individual on a short- 
term basis. There was no thought of what would benefit everyone, or of limiting harm 
to the global economy. 


Size Does Matter, but Not the Way You Think 


But just because cross-functionality can achieve great results, you shouldn’t play Noah 


and throw two of everything into a team. The team dynamic only works well in small 
teams. The classic formulation is seven people, plus or minus two, though I’ve seen 
teams as small as three function at a high level. What’s fascinating is that the data 
shows that if you have more than nine people on a team, their velocity actually slows 
down. That’s right. More resources make the team go slower. 


In software development there’s a term called “Brooks’s Law” that Fred Brooks 
first coined back in 1975 in his seminal book The Mythical Man-Month. Put simply, 
Brooks’s Law says “adding manpower to a late software project makes it later.” This 
has been borne out in study after study. Lawrence Putnam is a legendary figure in 
software development, and he has made it his life’s work to study how long things take 
to make and why. His work kept showing that projects with twenty or more people on 
them used more effort than those with five or fewer. Not just a little bit, but a lot. A 
large team would take about five times the number of hours that a small team would. 
He saw this again and again, and in the mid-1990s he decided to try to do a broad- 
based study to determine what the right team size is. So he looked at 491 medium-size 
projects at hundreds of different companies. These were all projects that required new 
products or features to be created, not a repurposing of old versions. He divided the 
projects by team size and noticed something right away. Once the teams grew larger 
than eight, they took dramatically longer to get things done. Groups made up of three to 
seven people required about 25 percent of the effort of groups of nine to twenty to get 
the same amount of work done. This result recurred over hundreds and hundreds of 
projects. That very large groups do Jess seems to be an ironclad rule of human nature. 


But why? To answer that, we have to look at the limitations of the human brain. 
You’ve probably heard of the classic George Miller study in 1956 showing that the 
maximum number of items the average person can retain in their short-term memory is 
seven. This is supposedly why telephone numbers are seven numbers long. The 
problem with Miller’s work is that later research has proved him wrong. 


In 2001, Nelson Cowan of the University of Missouri wondered whether that 
magic rule of seven was really true and conducted a wide survey of all the new 
research on the topic. It turns out that the number of items one can retain in short-term 
memory isn’t seven. It’s four.2 People often think that they can memorize more than 
that, using a mnemonic device or by just concentrating harder. But the research is 
fairly clear that we can only remember four “chunks” of data. The classic example is 
giving someone the following series of twelve letters: fbicbsibmirs. People can 
usually remember about four of those letters—unless they notice that they can be 
“chunked” into well-known acronyms: FBI, CBS, IBM, IRS. If you can link things in 
your short-term memory to long-term memory associations, you can hold more. But the 
part of the mind that focuses—the conscious part—can only hold about four distinct 


items at once. 


So there’s a hardwired limit to what our brain can hold at any one time. Which 
leads us back to Brooks. When he tried to figure out why adding more people to a 
project made it take longer, he discovered two reasons. The first is the time it takes to 
bring people up to speed. As you’d expect, bringing a new person up to speed slows 
down everyone else. The second reason has to do not only with how we think but, 
quite literally, with what our brains are capable of thinking. The number of 
communication channels increases dramatically with the number of people, and our 
brains just can’t handle it. 


If you want to calculate the impact of group size, you take the number of people 
on a team, multiply by “that number minus one,” and divide by two. Communication 
channels = n (n—1)/2. So, for example, if you have five people, you have ten channels. 
Six people, fifteen channels. Seven, twenty-one. Eight, twenty-eight. Nine, thirty-six. 
Ten, forty-five. Our brains simply can’t keep up with that many people at once. We 
don’t know what everyone is doing. And we slow down as we try to figure it out. 


Just as on a Special Forces team, everyone on a Scrum team has to know what 
everyone else is doing. All the work being done, the challenges faced, the progress 
made, has to be transparent to everyone else. And if the team gets too big, the ability 
of everyone to communicate clearly with everyone else, all the time, gets muddled. 
There are too many crosscurrents. Often, the team socially and functionally breaks into 
sub-teams that begin working at cross-purposes. The cross-functionality is lost. 
Meetings that took minutes now take hours. 


Don’t do it. Keep your teams small. 


The Scrum Master 


With the first Scrum team, I regularly showed them a video of the All Blacks rugby 
team getting ready for a game. The All Blacks, a legendary team from the small 
country of New Zealand, are a transcendent team. Before every game they perform the 
Maori warrior ceremony of the haka. The haka is a warrior dance that charges up 
people about to go into battle. While watching it, you can almost see the energy come 
out of each player and coalesce into a greater whole. With synchronized stomping and 
clapping and chanting—tritualized movements of cutting an enemy’s throat—you can 
see ordinary men transform themselves into something bigger, something greater. 
They’ re invoking a warrior spirit that does not accept defeat or dismay. 


It took a few viewings of the video, but my team of slightly-out-of-shape 
computer programmers eventually started to talk about how they could be that way. 
They came up with four aspects worthy of emulation. The first was intense focus on 


the goal, built up and energized by the Maori chant. The second was radical 
collaboration—arms and bodies locked together, pushing for the same goal. The third 
was hunger to crush—anything in their way was to be obliterated. The fourth was 
universal excitement when any team member broke through with the ball. Who it was 
didn’t matter. That it happened was cause for celebration. 


So we set up this framework ofSprints and Daily Stand-up meetings and 
Reviews and Retrospectives, and I realized we needed someone whose job it was to 
make sure the process itself was effective. Not a manager—more of a servant-leader, 
something between a team captain and a coach. As we were watching the All Blacks 
every day, I asked the team what we should call this person. They decided on “Scrum 
Master.” He or she would facilitate all the meetings, make sure there was 
transparency, and, most important, help the team discover what was getting in their 
way. The key part of that was to realize that often the impediments aren’t simply that 
the machine doesn’t work or that Jim in accounting is a jerk—it’s the process itself. It 
was the Scrum Master’s job to guide the team toward continuous improvement—to 
ask with regularity, “How can we do what we do better?” 


Ideally, at the end of each iteration, each Sprint, the team would look closely at 
itself—at its interactions, practices, and processes—and ask two questions: “What 
can we change about how we work?” and “What is our biggest sticking point?” If 
those questions are answered forthrightly, a team can go faster than anyone ever 
imagined. 


Don’t Hate the Player, Hate the Game 


It often turns out that low team morale, cohesion, and productivity are based on a 
fundamental misunderstanding of how humans work. How many times have you gotten 
together with a colleague and started bitching about a third who “isn’t pulling her 
weight” or “always slows us down” or “makes stupid decisions’? Or have you been 
with a group confronting a problem and the first thing that everyone does is try to fix 
blame? 


I’m willing to bet each and every one of you has been in a meeting like that. I’d 
also bet that each and every one of you, at one time or another, has been the person 
who has ended up being blamed for the problem. But I’d also be willing to bet that 
when you’re blaming someone, you’re finding fault with them personally, while if you 
are being blamed, you’re much more aware of the situational factors that led to the 
problem and why you acted the way you did. And you know what? When you’re 
talking about yourself, you’re absolutely right. When talking about others, though, 
you’re making one of the most common—and destructive—human errors in judging 
other people’s actions. It even has a name: “Fundamental Attribution Error.” 


Some fascinating studies related to this are laid out in the book /nduction: 
Processes of Inference, Learning, and Discovery, by John H. Holland et al. One 
paper cited in the book was published in the early 1970s, so this isn’t new. This is old 
stuff that has been reproduced over and over and over again. It’s all about what makes 
humans tick. Anyway, this group of researchers gathered together a bunch of male 
college students and asked them a couple of simple questions: “Why did you choose 
your major?” and “Why are you dating the person you are?” And then the researchers 
asked their subjects to answer the same questions about their best friend. Important 
differences emerged. When the students talked about themselves, they talked not about 
themselves personally but, rather, what they were asked about. They said such things 
as, “Chemistry is a high-paying field” about their major, and “She’s a very warm 
person” about their girlfriend. But when they talked about their friends, they talked 
about their friends’ abilities and needs—things such as, “He was always good at 


math,” or “He’s kind of dependent and needs a take-charge kind of woman.”!2 


This way of perceiving the world is funny when you see it in others. It’s so 
obvious that they’re making misjudgments. But before you laugh, you need to own up 
that you do it all the time as well. Everyone does. We all perceive ourselves as 
responding to a situation, while we see others as motivated by their character. One 
amusing side effect is that when we’re asked to report on our personality traits and 
those of our friends, we always paint ourselves as far more boring. We say we have 
dramatically fewer character traits than our friends. 


The authors of /nduction draw an interesting parallel between how we think 
mistakenly about social motivations and how nonscientists or people with merely an 
intuitive understanding of physics view the physical world. 


An intuitive physicist might explain why a rock falls by saying the rock itself has 
the intrinsic quality of gravity, rather than saying that gravity 1s part of a system of 
forces acting on the rock. In the same way, when we talk about others, we talk about 
their inherent properties, rather than see those properties in relation to the external 
environment. In fact, it’s those interactions with our environment that drive our 
behavior. It’s the system that surrounds us, rather than any intrinsic quality, that 
accounts for the vast majority of our behavior. What Scrum is designed to do is change 
that system. Instead of looking for blame and fault, it rewards positive behavior by 
focusing people on working together and getting things done. 


Perhaps the most famous demonstration of this human reaction to systems was the 
Milgram experiment on obedience to authority figures, which was done in the early 
1960s at Yale University. The experiment was simple and, to modern eyes, somewhat 
cruel. It was also devastating and powerful and is taught in every first-year 
psychology course. Dr. Stanley Milgram, a professor at Yale, had a question that was 


quite apropos then. Three months before the first experiments began, Adolf Eichmann, 
the architect of the Holocaust, went on trial. 


One of the most persistent questions surrounding the Holocaust was how so many 
millions of people could have been willing accomplices in such horror. Were 
Germans fundamentally morally reprehensible? Was there something intrinsically evil 
within their cultural makeup? Or were they really just following orders? It’s very easy 
to look at crimes against humanity and blame individuals for their actions. It’s the right 
thing to do, no? The question that Milgram wanted to answer, though, is: Are ordinary 
Americans so different from Germans? Would they have reacted differently in the 
same situation? And the uncomfortable answer is that no, Americans wouldn’t have 
behaved differently. In fact, given how many countries and cultures have replicated the 
experiment, no one would have. Given the right situation, we’re all capable of being 
Nazis. 


The experiment worked this way. The subject, an ordinary person, was told by 
someone wearing a white lab coat (which gave hima veneer of scientific authority) to 
administer ever-greater electrical shocks to a third person, an actor, who was in 
another room. The subject could hear but not see the actor. As the shocks increased, 
the actor would begin to scream and shout and beg. Eventually the actor (who in some 
versions of the experiment told the subject he had a heart condition) would start 
banging on the wall, yelling for the experiment to stop. Finally, he would go silent. 


Some people paused at 135 volts, as the actor screamed, and asked about the 
purpose of the experiment. Almost all continued after they were assured that they 
wouldn’t be held responsible. Some subjects began to laugh nervously as they heard 
the cries of agony from the next room. When the subject wanted to stop, the “scientist” 
simply said, “Please continue.” And if the subject wouldn’t, the scientist would go on, 
“The experiment requires that you continue.” If still nothing, the scientist would add, 
“Tt is absolutely essential that you continue.” Most subjects appeared to be under great 
stress and sweated profusely. They exhibited an elevated pulse and temperature as the 
“fight-or-flight’ instinct took hold. And then, if they still wouldn’t press the button, the 
scientist would try one last time. “You have no other choice. You must go on.” 


Almost everyone did, delivering the final shock to someone who’d been 
screaming and then gone silent. Milgram summarized the implications this way in his 
1974 article “The Perils of Obedience”: 


Ordinary people, simply doing their jobs, and without any particular hostility on 
their part, can become agents in a terrible destructive process. Moreover, even 
when the destructive effects of their work become patently clear, and they are 


asked to carry out actions incompatible with fundamental standards of morality, 
relatively few people have the resources needed to resist authority. 


When this experiment is discussed in classrooms, it is usually pointed out to 
students that it is the system within which those ordinary people were operating that 
was the culprit, rather than the people themselves. But it’s a hard lesson to internalize, 
because if you accept the truth of that, what does it say about you? 


What it says is that we’re al/ creatures of the system we find ourselves embedded 
in. What Scrum does is accept this reality, and, instead of seeking someone to blame, 
it tries to examine the system that produced the failure and fix it. 


Another experiment that illuminates a similar phenomenon was carried out at a 
theological seminary in the early seventies. You’d think that seminarians would be the 
most compassionate people on the planet, right? The subjects of the experiment were 
told that they had to give a sermon on the other side of campus. Some were told they 
had to hurry, because people were already waiting for them, and they were late. 
Others weren’t told to hurry. As they made their way across the school grounds, each 
seminarian passed someone moaning for help in a doorway. How many of the people 
who were told they had to hurry stopped to help? Ten percent. Of seminarians. 


Yet people want to blame individuals, not systems. It just feels better. The 
Fundamental Attribution Error appeals to our sense of justice. If we can blame 
someone else, we insulate ourselves from the possibility that we’d do the same thing 
—that we’re just as likely to press that button as anyone else, given the right 
circumstances. 


How does this error of blaming individuals rather than systems manifest in 
business? I have two good examples, the first being the New United Motor 
Manufacturing, Inc., (NUMMI) automotive plant in Fremont, California. It was a joint 
venture between General Motors and Toyota. The plant was closed by GM in 1982. 
Management considered the workforce the worst in America. People drank on the job, 
didn’t show up for work, and subtly sabotaged the cars (by, for example, putting a 
Coke bottle inside a door, where it would rattle and annoy customers). Toyota 
reopened the plant in 1984. GM told them about how awful the workers were but that 
the managers were great and they should rehire them. Instead, Toyota declined to 
rehire the managers and rehired most of the original workforce—even sent some of 
them to Japan to learn the Toyota Production System. Almost immediately the NUMMI 
plant was producing cars with the same precision and as few defects as cars that were 
produced in Japan. Same people, different system. GM never reached those levels of 
quality at any of its other American plants. It pulled out of the joint operating 
agreement the same year it went bankrupt. 


The second example that comes to mind is slightly different. It reminds me of 
how much of a “default position” it is for people to start looking for someone to blame 
for a problem rather than search for a solution. It has to do with how the venture 
capitalists I work with operate when they decide to invest in a company. I was 
surprised when I first joined OpenView Venture Partners that, unlike many VC firms, 
they don’t really care how the company spent the money they had before their 
investment. History doesn’t matter. OpenView decides whether to spend money based 
on a firm’s current state—everything else is immaterial. They want to know how their 
money is going to be spent. How the company spent the other guys’ money isn’t 
important. It’s only the future—only the so/utions—that matter. 


Reaching “Great” 


When a team starts to align and synchronize, it can seem magical. You feel it when you 
walk into a room with them. You see it as they take the field. They look as if they’re 
floating; they’ ve become greater than themselves. 


I was at a friend’s house recently in Copenhagen. As you can imagine, since he’s 
European, he’s a major soccer fan. I’m not sure what tournament his favorite team was 
playing in, but it was intense, watching him jump up and down and scream at the 
television. This was a sports fan in high dudgeon. And then came this moment: the 
score was tied, the seconds were ticking down, and his team had the ball. From maybe 
a quarter of the way down the field, without looking at where his teammates were, a 
forward kicked the ball into a mass of players in front of the goal. The problem was, 
none were on the kicker’s team. For an instant I felt deflated; then, suddenly, a player 
on my friend’s team appeared—at just the right place and time, and headed the ball 
into the goal. The player had run full speed from midfield into the mass of opponents 
in front of the goal, where he seized the opportunity to head the ball. It was a total 
surprise. The forward who’d originally kicked the ball had faith, though, that his 
teammate would be where he was supposed to be. And that teammate had faith that the 
ball would be placed where he could do something with it. It was the kind of 
synchronicity that is inspiring to watch. 


And that’s a place I want to help people reach with Scrum. It’s not impossible. 
It’s not only the elites and athletes and special people who can do this. It’s about 
setting up the right framework with the right incentives and giving people the freedom, 
respect, and authority to do things themselves. Greatness can’t be imposed; it has to 
come from within. But it does live within all of us. 


THE TAKEAWAY 


Pull the Right Lever. Change Team performance. That has much more 
impact—by several orders of magnitude—than individual performance. 


Transcendence. Great teams have a purpose that is greater than the 
individual; e.g., burying General MacArthur, winning the NBA 
championship. 


Autonomy. Give teams the freedom to make decisions on how to take action 
—to be respected as masters of their craft. The ability to improvise will 
make all the difference, whether the unit is reporting on a revolution in the 
Middle East or making a sale. 


Cross-functional. The team must have every skill needed to complete a 
project, whether the mission is to deliver Salesforce.com software or 
capture terrorists in Iraq. 


Small Wins. Small teams get work done faster than big teams. The rule of 
thumb is seven team members—plus or minus two. Err on the small side. 


Blame Is Stupid. Don’t look for bad people; look for bad systems—ones 
that incentivize bad behavior and reward poor performance. 


CHAPTER FOUR 


Time 


Time is the ultimate limiter of human endeavor, affecting everything from how much 
we work, to how long things take, to how successful we are. The relentless one-way 
flow of time fundamentally shapes how we view the world and ourselves. As the 
seventeenth-century British poet Andrew Marvell famously put it, “Had we but world 
enough, and time” anything could be accomplished. But, of course, a sense of mortality 
hovers over our every effort. We know our time is limited. As such, isn’t it the 
greatest of crimes to waste it? Marvell, again: 


Thus, though we cannot make our sun 


Stand still, yet we will make him run. 


But how do we do that? It’s easy enough to shout “Carpe diem!” from a stage to 
inspire a crowd, but how do you actually pull it off? A lot of work is telling people to 
sit down, buckle up, and put in long hours. “Don’t think about the outside world,” our 
bosses tell us implicitly. “Don’t worry about your kids, going surfing, or even dinner 
—just work, and then work harder, and you’ 11 be rewarded. You’ ll get that promotion. 
You'll make that sale. You’ ll finish that project.” 


While I have nothing against promotions, sales, or projects, it’s just a fact that 
humans are absolutely terrible at working that way. We’re lousy focusers, we spend 
far more hours in the office than needed, and we’re horrible estimators of how long 
things will take. This is a// people I’m talking about—it’s how we humans simply are. 


When I sat down to develop Scrum, I had no intention of creating a new 
“process.” I simply wanted to gather together all the research that had been done for 
decades on how people work best and emulate that. I wanted to incorporate best 
practices and steal any better ideas I came across. Right before the first real Scrum at 
Easel in 1993 I was working at a company just blocks from the MIT Media Lab, and I 
stole an idea from the lab that has become the core of Scrum: the Sprint. 


The Sprint 


In the early 1990s the Media Lab was coming up with all sorts of neat stuff. This was 
during the time that the World Wide Web was being birthed, and they were doing 
everything from robots to the electronic ink that makes e-readers possible to new ways 
to encode sound. It was an incredibly heady time, and I tended to hire students coming 
out of the lab because they were chock-full of ideas, had an incredible ability to make 


things that were cool, and they could build them fast. 


Their speed owed itself to a policy that the Media Lab had for all its projects. 
Every three weeks each team had to demonstrate to their colleagues what it was 
working on. This was an open demonstration; anyone could come. And if that demo 
wasn’t both working and cool, lab directors killed the project. This forced the students 
to build neat stuff fast and, most important, to get immediate feedback on it. 


Think about many of the projects that you do. I'd bet that you seldom get feedback 
on them until completion—and that could be months, even years, away. You might be 
heading completely in the wrong direction for months and not suspect it. That’s 
throwing huge chunks of your life away. In business it could mean the difference 
between success and failure. I see this happen all the time: a company will spend 
years on a project that seemed like a good idea when the workers started on it, but by 
the time they cross the finish line, the market has fundamentally changed. The sooner 
you give things to your customers, the quicker they can tell you if you’re making 
something they need. 


So when I started the first Scrum at Easel and told the CEO I wasn’t going to 
show him a long and detailed Gantt chart that we both knew was wrong, he said, 
“Fine. What are you going to show me?” And I told him that each month I’'d show him 
a piece of working software. Not something that works in the back end. Not some 
piece of architecture. A piece of software that a customer can actually use. A fully 
implemented feature. 


“Okay,” he said. “Do that.” 


And so my team embarked on what we called “Sprints.” We called them that 
because the name evoked a quality of intensity. We were going to work all out for a 
short period of time and then stop to see where we were. 


“Team WIKISPEED” is a group founded by the wonderfully named Joe Justice. 
They make cars. Cars that get over a hundred miles to the gallon, are street legal, get 
five-star crash ratings, go 140 miles per hour, and that you can buy for less than the 
cost of a Camry. WIKISPEED is still constantly improving the vehicle, but if you want 
to buy one, deposit twenty-five grand at wikispeed.com, and they’ll get you a car in 
three months. And they use Scrum to do it. They, like many of the best teams now, 
work in one-week Sprints. Every Thursday they sit down and look at the massive 
backlog of things they have to do, everything from prototyping a new dashboard design 
to testing turn signals. They’ ve prioritized that list, and then they say, “Okay, given that 
list, how many things can we do this week?” And by “do” they mean “done”—done 
completely. These new features work. The car drives. Each week. Each Sprint. 


Walking into Team WIKISPEED’s lair north of Seattle on an average Thursday, 


you see the glorious organized chaos that is a machine shop. There are bins of tools 
and saws and electronics and fasteners and wrenches. A CNC router sits in a corner 
next to the half-constructed frame of a car in bay three. A drill press and metal bender 
sit off to one side like puppies eager to be played with. Above the frame on the day 
we visit 1s a picture of the person who’s buying the car—Tim Myer. He likes 
mountain climbing and chips and cider. He doesn’t like not knowing what’s going on 
or not having options. You can find him in the hills on weekends and square dancing at 
the Tractor every other Monday night. 


In front, in bay one, sits the first car Team WIKISPEED made—the car that 
participated in a ten-million-dollar XPrize contest for cars achieving a fuel efficiency 
of 100 mpg. Team WIKISPEED came in tenth, beating out more than a hundred 
competitors from big auto companies and universities. As a result, they were invited 
to the 2011 Detroit Auto Show and were put right in front, between Chevy and Ford. 
This car is now their test bed for new ideas. 


Next to the car is a twelve-foot-high wall of whiteboard stretching the width of 
the shop. On it are dozens and dozens of one of the most common artifacts found in 
Scrum: sticky notes. On each of these brightly colored Post-its is a thing to be done: 
“drill tube for modular steering rack” ... “prepare interior mold” ... “install inner 
fender liners to prevent splash from tires,” etc. 


The board is divided into a few columns: Backlog ... Doing ... Done. Each 
Sprint, Team WIKISPEED’s members put into the Backlog column as many Post-its as 
they think can get done that week. As the week goes by, a member of the team will take 
up one of those tasks and move the sticky to Doing. When it’s finished, it'll get moved 
to Done. Everyone on the team can see what everyone else is working on at every 
moment. 


An important point: nothing gets moved to Done unless it can be used by the 
customer. In other words, you can drive the car. And if someone drives the car and 
says, “Hey, the turn signals are sticking,” that problem is dealt with in the next Sprint. 


Sprints are what are often called “time boxes.” They’re of a set duration. You 
don’t do a one-week Sprint and then a three-week Sprint. You have to be consistent. 
You want to establish a work rhythm where people know how much they can get done 
in a set period of time. Often that quantity surprises them. 


One crucial element of an individual Sprint, though, is that once the team commits 
to what they’re going to accomplish, the tasks are locked in. Nothing else can be 
added by anyone outside the team. Later, Pll get further into the reasons why, but for 
now just know that interfering and distracting the team slows its speed dramatically. 


As I mentioned, in the first Scrum we were running four-week Sprints. Near the 


end of the first Sprint we felt we weren’t going fast enough—that we could do more. 
We looked at videos of the All Blacks doing the haka and breaking through opposing 
lines. Why aren't we like that? we asked ourselves. Why don't we have that kind of 
spirit? Our goal was not just to be a good team, but the best. How could we do that? 
Once again, the answer turned out to be something simple that we stole from someone 
else—the daily meeting. 


Daily Stand-Up 


Outside a city I can’t name, in a company I can’t mention, a group of people gathers 
every day to ponder how to put other people into space. Since rocket ships are really 
intercontinental ballistic missiles with a human payload, there is a certain amount of 
security and secrecy in the private space-travel effort. And it is a business, not merely 
a billionaire’s pipe dream. As I write, another private rocket just docked with the 
International Space Station for the second time. Even the US government doesn’t have 
that capability at the moment. 


But in this particular building, on this particular day, these particular people are 
wrestling with how big the box should be that holds the rocket’s avionics package. 
Avionics tell the rocket where it is, where it’s going, and how to get there. Think of it 
as the rocket ship’s mind. 


There are two teams: one hardware and one software, each composed of about 
seven people. Every day each team gathers in front of a floor-to-ceiling whiteboard 
stretching from one end of the wall to the other. Just like at Team WIKISPEED there 
are a few columns drawn on the board: Backlog, Doing, Done. Listed in the columns 
are only the things that the team needs to get done in this Sprint. The tasks range from 
working with one of half a dozen specialty circuit-board vendors to mapping out how 
the accelerometer will talk to the rest of the ship. The Scrum Master, the person in 
charge of running the process, asks each team member three questions: 


1. What did you do yesterday to help the team finish the Sprint? 
2. What will you do today to help the team finish the Sprint? 
3. What obstacles are getting in the team’s way? 


That’s it. That’s the whole meeting. If it takes more than fifteen minutes, you’re 
doing it wrong. What this does is help the whole team know exactly where everything 
is in the Sprint. Are all the tasks going to be completed on time? Are there 
opportunities to help other team members overcome obstacles? There’s no assigning 
of tasks from above—the team is autonomous; they do that. There’s no detailed 
reporting to management. Anyone in management or on another team can walk by and 


look at the avionics Scrum board and know exactly where everything stands. 


So when the first Scrum team wanted to figure out how they could be like the All 
Blacks, they went into the literature to find out how the best teams did it. One of the 
great things about software development is that the situation early on was so bad, and 
so much money was being wasted—billions and billions each year—that people spent 
a lot of time studying why, and there was data on everything. 


One of the people who spent years looking at how things are made in the 
software business was Jim Coplien at AT&T’s legendary Bell Labs. Coplien, who is 
referred to both by himself and others as “The Cope,” spent years looking at hundreds 
of software projects, trying to figure out why a small minority went well while the 
majority were disasters. In the early 1990s he was invited to look at a project at 
Borland Software Corporation that was making a new spreadsheet product called 
“Quattro Pro for Windows.” For the project, one million lines of software code had 
been created. They took thirty-one months to produce and were the output of eight 
people. That means each team member produced one thousand lines of code each 
week. That’s the fastest of any team on record, and Jim wanted to know how they did 
it. 


What he did was map all the communication flows within the team—who was 
talking to whom, where information was flowing, and where it wasn’t. This type of 
mapping is a tool that can be used to spot bottlenecks or information hoarders. The 
greater the communication saturation—the more everyone knows everything—the 
faster the team. Basically, the metric spun off by this type of analysis measures how 
well everyone knows what they need to get their work done. Borland had the highest 
rating ever: 90 percent. Most companies hover around 20 percent. 


So how could we get that kind of saturation on our team? The thing that cripples 
communication saturation is specialization—the number of roles and titles in a group. 
If people have a special title, they tend to do only things that seem a match for that 
title. And to protect the power of that role, they tend to hold on to specific knowledge. 


So we got rid of all titles. I called everyone in and told them to rip up their 
business cards. If someone wanted to put a title on their resume, they could do it for 
external use only. In here, where the work was done, there were only team members. 


The other ingredient in the Borland team’s “secret sauce” was that they would 
have everyone on the team meet every single day to discuss how they were 
performing. Getting everyone together in a room was key, because it gave the team the 
opportunity to self-organize around challenges. If someone was stuck with a problem 
—if the accelerometer wasn’t talking to the altimeter—everyone saw that the 
impediment could block the whole Sprint, and they swarmed on it, making sure it got 


fixed pronto. 


At Borland the daily meeting was an hour at least. That struck me as too long, so I 
looked at the core things that need to be communicated in that huddle and came up with 
the three questions. 


And that’s how the daily meeting came to operate. We had certain rules. The 
meeting was held at the same time every day, and everyone had to be there. If the 
entire team wasn’t present, communication simply didn’t happen. And it didn’t matter 
what time of day the meeting took place, as long as it was at the same time every day. 
The point was to give the team a regular heartbeat. 


The second rule was that the meeting couldn’t last more than fifteen minutes. We 
wanted it to be crisp, direct, and to the point. If something required further discussion, 
we noted it and met further after the daily meeting. The idea was to get the most 
actionable and valuable information in the least amount of time. 


The third rule was that everyone had to actively participate. To help this happen, 
I said that everyone had to stand up. That way there’d be active talking and listening 
going on. It also would keep the meetings short. 


This is the reason such a meeting is often called the Daily Stand-up or Daily 
Scrum. It doesn’t really matter what you call it. It has to be at the same time every day, 
with the same three questions, with everyone standing up, and last no more than fifteen 
minutes. 


The problem that I frequently see crop up is that people have a tendency to treat 
the Daily Stand-up as simply individual reporting. “I did this ... P11 do that’—then on 
to the next person. The more optimum approach 1s closer to a football huddle. A wide 
receiver might say, “I’m having a problem with that defensive lineman,” to which an 
offensive blocker might respond, “Ill take care of that. Pll open that line.” Or the 
quarterback might say, “Our running game 1s hitting a wall; let’s surprise them with a 
pass to the left.” The idea is for the team to quickly confer on how to move toward 
victory—t.e., complete the Sprint. Passivity is not only lazy, it actively hurts the rest 
of the team’s performance. Once spotted, it needs to be eliminated immediately. 


I want aggressive teams—ones that come out of the daily meeting knowing the 
most important thing they need to accomplish that day. One person will hear another 
say that a task will take a day, but another team member might know how to do it in an 
hour if they work together. I want teams emerging from that meeting saying things like, 
“Let’s nail this. Let’s do this.” The team needs to want to be great. 


My standard speech to teams large and small is: “Do you really want to suck 
forever? Is that what your motivation is in life? Because it’s a choice, you know—you 


don’t have to be that way.” A team has to demand greatness from itself. 


At Easel, with the first Scrum team, we implemented the Daily Stand-up during 
the third Sprint. We’d planned out four weeks of work for that Sprint—pretty much the 
same workload as the previous month. We finished it all in a week. A 400-percent 
improvement. That first Friday the whole team just looked around at one another and 
said, “Wow.” That’s when I knew I might be on to something. 


Time and Time Again 


That kind of improvement was baked into Scrum from that third Sprint. It’s the design 
goal of Scrum. In certain cases I’ve seen highly disciplined teams increase their 
productivity eight times. That’s what makes Scrum so revolutionary. You can get more 
stuff done faster and cheaper—twice the work in half the time. And remember, it’s not 
just in business that time is important. Time makes up your life, so wasting it is 
actually a slow form of suicide. 


What Scrum does is alter the very way you think about time. After engaging for a 
while in Sprints and Stand-ups, you stop seeing time as a linear arrow into the future 
but, rather, as something that is fundamentally cyclical. Each Sprint is an opportunity 
to do something totally new; each day, a chance to improve. Scrum encourages a 
holistic worldview. The person who commits to it will value each moment as a 
returning cycle of breath and life. 


I’ve always been dismayed by how long house-remodeling jobs can take. My 
wife and I used to remind each other, it’ll take twice as long and cost twice as much as 
we think. And that’s if we were lucky. I’m sure you’ve heard the same horror stories 
as I: the kitchen job that was supposed to take two weeks that ended up taking six, 
leaving the family eating takeout for more than a month; the electrical work that 
exceeded the estimate by three times; the minor job that just seemed to take forever to 
get done. Well, a couple of years ago my friend and fellow Agile thinker Eelco 
Rustenburg told me at dinner that he’d decided to redo his house—the whole thing, 
soup to nuts. He’d be tackling all the rooms, installing new wiring, putting in new 
appliances, slapping a fresh coat of paint on everything. And it was only going to take 
six weeks. 


We all laughed and began to regale Eelco with our remodeling tales of woe. “Six 
weeks for a whole house?” I said, laughing. ““Not going to happen. It took six weeks to 
redo my kitchen, though they promised me two. You'll be living in a hotel for the rest 
of the year.” 


“Nope,” he said. “It’s going to be on time and on budget. I’m going to do it using 
Scrum.” 


Now, that got me excited—the idea of using Scrum in a completely different 
arena than software. I ran into Eelco about six months later and asked him how it had 
gone. “Great,” he said. “Six weeks to the day. Now my neighbor, that’s another 
story.” 


Here’s what happened. Eelco decided to make the contractors work as a Scrum 
team. He had weekly projects they had to move to Done, and in the contractor’s trailer 
parked in his front lawn he had a Scrum board full of sticky notes listing out tasks. 
Every morning he’d gather the carpenters, the electricians, the plumbers, or whoever 
else was needed for that week’s Sprint and go over what was done the day before, 
what they were going to get done today, and what was getting 1n their way. 


Eelco says it made them think and communicate about the project in a different 
way than they had before. Plumbers and carpenters talked about how they could help 
one another work faster. Shortages of materials were discovered before their absence 
stopped all progress. But he said the main thing the Stand-ups did was remove 
dependencies. On any construction project a lot of time is spent waiting for one part of 
the job to be done before the next can begin, and often these phases involve different 
skill sets—electrical installation and drywall hanging, for instance. What the Daily 
Stand-up meeting did was get all these people into a room where they quickly figured 
out how they could work together as a team. They were no longer simply individuals 
with separate skills but, rather, a team trying to move a house to Done. 


And it worked. Six weeks later the project was completed. Eelco and his family 
moved back in. Life was good. When he told me this, I was surprised, but I 
congratulated him on having some great contractors. But wait, he told me, that’s not the 
whole story. Down the block from his house a neighbor wanted to do almost exactly 
the same work on his house. They both lived in an old part of the Netherlands, and 
their houses had been built at exactly the same time, to exactly the same plan. The 
neighbor saw what a great job the contractors had done on Eelco’s place and figured 
he’d repeat the magic. 


The same workers were hired, but this time it took them three months. Same 
people. Same kind of house. Same job. Twice the time and, of course, twice the 
money. The only difference was that the neighbor didn’t use Scrum. The problems that 
Scrum forces to the surface weren’t discovered until too late. People didn’t coordinate 
in the same way and were forced to wait for someone else to be done to begin their 
work. Eelco’s neighbor ended up paying nearly twice as much as Eelco, most of that 
to people waiting for someone else to get their job done. 


Think about your job. How much of your time is wasted while you’re waiting for 
someone else to finish their work, or for information to be delivered, or because 
you’re trying to do too many things at once? Maybe you would rather be at work all 


day—wme, I'd rather be surfing. 


THE TAKEAWAY 


Time Is Finite. Treat It That Way. Break down your work into what can 
be accomplished in a regular, set, short period—optimally one to four 
weeks. And if you’ve caught the Scrum fever, call it a Sprint. 


Demo or Die. At the end of each Sprint, have something that’s done— 
something that can be used (to fly, drive, whatever). 


Throw Away Your Business Cards. Titles are specialized status markers. 
Be known for what you do, not how you're referred to. 


Everyone Knows Everything. Communication saturation accelerates work. 


One Meeting a Day. When it comes to team check-ins, once a day is 
enough. Get together for fifteen minutes at the Daily Stand-up, see what can 
be done to increase speed, and do it. 


CHAPTER FIVE 


Waste Is a Crime 


The heart of Scrum is rhythm. Rhythm is deeply important to human beings. Its beat is 
heard in the thrumming of our blood and rooted in some of the deepest recesses of our 
brains. We’re pattern seekers, driven to seek out rhythm in all aspects of our lives. 


However, the patterns we seek aren’t necessarily rewarding or optimized to 
bring us happiness. For example, there are the negative rhythms of the addict and the 
depressed. You can walk the halls of just about any office building and see these 
negative patterns made manifest. They’re likely to be found anywhere that someone 
feels frustrated at being stymied, or quietly desperate as it dawns on them that they’re 
trapped in an uncaring system, or angry at being viewed as a cog in a machine. 


This is part of the human experience. You can go back thousands of years and 
read the writings of other people, just like us, whose lives were caught up in a system 
they felt helpless against. But we seem to have mastered that trapped feeling sometime 
during the twentieth century. Throughout the business environment especially, we 
created an acute depersonalization that seems dictated by fate. 


What Scrum does is create a different kind of pattern. It accepts that we’re habit- 
driven creatures, seekers of rhythm, somewhat predictable, but also somewhat magical 
and capable of greatness. When I created Scrum, I thought, What if I can take human 
patterns and make them positive rather than negative? What if I can design a 
virtuous, self-reinforcing cycle that encourages the best parts of ourselves and 
diminishes the worst? In giving Scrum a daily and weekly rhythm, I guess what I was 
striving for was to offer people the chance to /ike the person they see in the mirror. 


But there are pitfalls. What look like virtuous patterns can end up being nothing 
but folly—nothing but waste. That’s what ’'m going to spend this chapter talking 
about: the waste that infects our work, the cancer that eats at our productivity, our 
organizations, our lives, and our society. 


The other day I was interviewing someone for a job at Scrum, Inc., and I asked 
why he wanted to work in a Scrum company. He told me a story. He worked at a 
company that put out textbooks and ancillary products like workbooks, course 
materials, presentations, etc. His job was to identify leading scholars in a particular 
field and work with them to produce these products. In a way it was exciting. He was 
a history major, a scholar of the American Colonial period, and he had a chance to 
work with some of the leading minds in his field. 


“I worked for a year,’ he said. “A year spent developing dozens of different 


products. At the end of the year, we reviewed for the first time what we’d 
accomplished. And fully half of the work I'd done over the past year was thrown 
away. Not because it wasn’t good, but because the market wasn’t there, or direction 
had changed. Six months of my life were completely and totally wasted.” 


At that point a certain indignation and anger crept into his voice. And then 
determination. “I hope that Scrum won’t let that happen, that my work will have 
purpose, that what I do will actually matter.” 


You might think that an extreme example. Fifty-percent waste. But it’s actually 
pretty good. When I go into a company I usually find that about 85 percent of effort is 
wasted. Only a sixth of any of the work done actually produces something of value. 
Deep within ourselves, as we repeat the rhythm of our days, we know that’s true. 
That’s why we all laugh, a bit nervously, at jokes about the inherent insanity and 
wastefulness of life in a modern corporation. 


I’m here to tell you that it shouldn’t be funny. It should be shameful. We should 
mourn the lives and potential we’re wasting. I briefly introduced Toyota’s Tatichi 
Ohno in the first chapter of this book, where he said, “Waste is a crime against society 
more than a business loss.” His thoughts about waste deeply influenced mine, and I 
want to spend some time talking about them. 


Ohno talked about three different types of waste. He used the Japanese words: 
Muri, waste through unreasonableness; Mura, waste through inconsistency; and Muda, 
waste through outcomes. These ideas are highly aligned with Deming’s PDCA cycle, 
which I wrote about earlier: Plan, Do, Check, Act. Plan means avoid Muri. Do means 
avoid Mura. Check means avoid Muda. Act means the will, motivation, and 
determination to do all that. I’m going to go through these steps one at a time and point 
out what to avoid—from waste in inventory, to the waste of not doing it right the first 
time, to the waste of working too hard, to the emotional waste of unreasonable 
expectations.- 


Do One Thing at a Time 


I often hear people brag about their ability to multitask. I’m sure you do too. If you 
don’t crow about it yourself, you know someone who does—the guy who does three 
projects at once, who drives and talks on his cell phone, who promotes his 
competence by complaining loudly about all the things he has to juggle every day. This 
sort of “busy-brag” 1s becoming part of our work culture. In job descriptions you now 
see requirements like “must be able to balance five projects simultaneously.” 


The ability to juggle seems so attractive—especially in an age in which 
information is flowing through a thousand different pipelines and “must do nows” are 


proliferating. We want to be that guy—the Super-Juggler. We tell ourselves we can. 
Unfortunately, we can’t. And the more we think we can, the worse we actually are at 
it. 


An especially apt example is that daily practice of multitasking: driving and 
talking on a cell phone. The research is very clear on this. People who drive while 
talking on cell phones—even the hands-free variety—get into more accidents than 
people who don’t. The problem is especially alarming when you consider that, 
according to the National Highway Transportation Safety Administration, at any given 
moment 8 percent of people on the road are talking on a cell phone. 


That is what multitasking has bequeathed us. 


Here’s a quote from my favorite paper on the subject: 


... even when participants direct their gaze at objects in the driving environment, 
they often fail to “see” them when they are talking on a cell phone because 
attention has been directed away from the external environment and toward an 


internal, cognitive context associated with the phone conversation.2 


That’s right, people will actually look at an object, the car they’re about to rear- 
end, or the tree they’re about to wrap their car around, and not see it. And yet, we 
persist in driving and talking on the phone. 


I can read your mind right now. You’re thinking, Well, other people can't do it. 
But me, I’m a high-powered executive” or “I’m smart. I can do it; they can t.”” The 
literature is pretty clear on the topic, though: if you think you’re good at it, you’re 
actually worse than everyone else. The University of Utah, which has done a lot of 
interesting research in this area, asked people whether they thought they were good at 
multitasking activities such as using a cell phone while driving, and then they tested 
them to see if they were right. The researchers’ conclusions: 


Perceptions of the ability to multi-task were found to be badly inflated; in fact, 
the majority of participants judged themselves to be above average in the ability 
to multi-task. These estimations had little grounding in reality. Thus, it appears 
that the people who are most likely to multi-task and most apt to use a cell phone 
while driving are those with the most inflated views of their abilities.4 

The lead author of the study, David Sanbonmatsu, told the NPR blog Shots in 


January of 2013, “People don’t multitask because they’re good at it. They do it 
because they are more distracted. They have trouble inhibiting the impulse to do 


another activity.” In other words, the people who multitask the most just can’t focus. 
They can’t help themselves. 


I probably shouldn’t say “they.” I should say “we.” We all do it. It’s hard not to. 
The key thing to remember is that it’s stupid. I want you to do a little exercise. It’s one 
that I have people do all the time in my training courses. It’s simple, but it shows the 
deep impact of focus and flow. It shows just how painful multitasking is to your brain, 
and how much it slows you down even when you think it speeds you up. It 
demonstrates just how wasteful it 1s. 


Here’s what I want you to do. The task is to write down the numbers 1-10, the 
Roman numerals 1—10 (I, II, Ill, IV, etc.), and the letters A-L. Time yourself doing 
this. You want to do it as fast as possible. But here’s how I want you to do it the first 
time. Write the Arabic numeral, the Roman numeral, then the letter, so your piece of 
paper looks like this: 


lI A 
211 B 
3STIC 


You’re doing each row at a time. Time yourself. Pll do it right now with you. 
Took me thirty-nine seconds. Now, instead of doing it by rows, do it by columns. So 
first you'll do all the Arabic numerals, then the Roman, then the letters. [1] do it too. 
Nineteen seconds. Simply by doing tasks one at a time, instead of switching from one 
context to another, I halved the amount of time it took me. 


Okay, Sutherland, | hear you saying, that’s all well and good for talking on the 
cell phone and making silly lists, but I run a business. I have to do a bunch of things 
at once—have my teams address five projects simultaneously. I have to remain 
competitive. I can’t afford not to. 


Here’s where the incredible amount of research done on software projects comes 
in handy again. Remember, people have done this research because they kept wasting 
hundreds of millions of dollars every year, and their products just got worse. And so, 
being the engineers they are, they started looking at the data and measuring everything. 
There’s a great chart that appears in one of the classic works on how to develop 


computer software, Quality Software Management by Gerald Weinberg:4 


Number of Simultaneous Percent of Time Available per Loss to Context 


Projects Project Switching 


1 100% 0% 

2 40% 20% 
, 20% 40% 
4 10% 60% 
= 5% 75% 


The “Loss to Context Switching” column is pure waste. That’s right: if you have 
five projects, a full 75 percent of your work goes nowhere—three-quarters of your 
day is flushed down the toilet. It’s why you couldn’t write the rows and columns at the 
same speed. It’s a result of the physical limitations of your brain. 


A scientist named Harold Pashler demonstrated this in the early 1990s. He called 
it “Dual Task Interference.” He conducted a few simple experiments. He would have 
one group do one really simple thing, say press a button if a light went on. And then 
he’d give another group that task plus another simple one, like pressing a different 
button depending on the color of the flashing light. As soon as another task was added, 
no matter how simple, the time involved doubled. Pashler theorized that there was 
some sort of processing bottleneck—that people can really only think about one thing 
at a time. He reckoned that a certain amount of effort is involved in “packing up” one 
process, reaching into your memory and pulling out another, and then running that job. 


And each time you switch tasks, that process takes time.* 


As a result, you don’t do it. You concentrate fully on one thing at a time. You talk 
on the cell phone, and even though all you’re discussing is picking up milk, you 
literally can’t see the car in front of you. Your brain can’t process those two things at 
the same time. There has been some recent research using fMRIs to map the brain as 
it’s actually thinking. The data show that it’s possible to think about two things at once 
only with one process running in each lobe of your brain. But even then, the scans 
indicate that the thinking isn’t happening simultaneously but, rather, the brain is 
switching from one task to another in serial fashion. Basically, there’s a control 


function, so you can’t argue with yourself too vigorously.® 


So back to work. What does this mean when you're trying to get things done? 
Well, let’s look at a typical team. This year they’ ve decided to do three projects. Let’s 
call them A, B, and C. And they plan out their year, saying they’I! do a little bit on this 
project, then that one, and then the next one, so their calendar looks like what’s shown 


on this page. 


By trying to do everything at once—the classic strategy—completing those three 
projects will take them till the end of July. But by approaching the aggregate in a 


Scrum fashion, by driving each project to Done one at a time, they minimize the cost of 
context switching. They’re able to finish by the beginning of May. 


They don’t change how big the project is, or what’s involved in creating it, but 
just by doing one thing exclusively before moving on, the work takes a little more than 
half as much time. Half. 


And the other half? That’s pure waste. Not a thing more is produced. Not a dollar 
saved. Not a new innovation implemented. It is just a waste of human life. It’s working 
for no purpose. 


PRIORITIZING BETWEEN PROJECTS 
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Traditional strategy: “Everything is important! Do it all at once!” ah ol '¢] 
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Agile strategy: “Priorities & focus!” 
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So that’s the cost of multitasking. We all live ina world where there are multiple 
demands on our time. People want different things from us: the phone rings with a 
really important call, the kids arrive home from school, the boss walks into our office. 
What I want you to do, though, is be conscious of the cost of context switching. It’s 
very real, and you should try to minimize it. 


If yowre working with something complicated—for example, writing a report, 
creating a presentation, developing a piece of software, or crafting a book, you’re 
holding an incredibly complex object in your mind. You must take into account dozens 
of factors, remember what you’ve done, where you want to go, and what the 
impediments might be. That’s a pretty tricky thing to do. And what happens if you’re 
interrupted or have to switch quickly to another project, even just for a moment? You 
guessed it: that carefully built mental architecture collapses. It can take hours of work 
just to get back to the same state of awareness. That’s the cost. So minimize that waste 
by trying to do all at once those tasks that require a specific kind of concentration. Put 
those tasks into blocks of time where it’s possible to shut off your phone and put up a 
“Do not disturb!” sign. 


Some research has actually been done that shows that multitasking not only 
wastes your time but makes you stupid. A study done at the University of London back 
in 20052 (admittedly, a very small non-peer-reviewed study, but still) measured how 
stupid multitasking can make you. Psychiatrist Glenn Wilson took four men and four 
women and tested their IQ under quiet conditions and distracting conditions (phones 
ringing, e-mail arriving). During the tests he measured the subjects’ skin conductance, 
heart rate, and blood pressure. And, interestingly, the mean IQ scores of the subjects 
dropped by more than ten points when in distracting environments. Even more 
interesting, the drop-off was worse for men than women. (Perhaps, for some reason, 
women are more habituated to distraction.) 


Half Done Isn’t Done at All 


As I’ve mentioned, Scrum takes a lot of its thinking from the Japanese manufacturing 
model that was codified in the classic book Joyota Production System by Tatichi 
Ohno. In the United States this model has been interpreted as “Lean” manufacturing. 
Basically, the idea is to eliminate as much waste as possible on the factory floor. 
Now, most of us aren’t looking to improve flow through an automobile plant, but some 
of the ideas are applicable to any kind of work at all. 


One idea I want to address here is called “Work in Process,” or sometimes just 
“inventory.” The idea is that it’s wasteful to have a bunch of stuff lying around that 
isn’t being used to build something. That stuff, whether it be car doors or widgets, 
actually costs money, and if it’s sitting around on the factory floor, it means that huge 


amounts of money are bound up in inventory that isn’t actually needed right then. This 
changes how you look at things that are in process. If, for example, all an auto 
company has is a bunch of half-built cars, it has expended a lot of money and effort but 
hasn’t created anything of real value. In Lean manufacturing, the idea is to minimize 
the amount of half-built stuff lying around. 


The power of that idea applies to every type of work. Let’s take something very 
simple that nearly every married adult on the planet has: the “honey-do” list. In any 
given week, my list usually has on it ten to twenty chores that I need to take care of. 
They range from repainting the bathroom to picking up more dog food, from paying the 
mortgage to raking leaves. This is the stuff of daily life, the friction of being a fully 
integrated member of society. Now, there are a bunch of different ways of attacking 
that list. But the biggest mistake you can make 1s to try to do five things at once. That’s 
multitasking, and you probably won’t get all of them done, which leaves you with 
work in process. 


Imagine (or, if you’re unfortunate, remember) having five tasks partially done. 
You’ve painted one wall of the bathroom, the dog food is still in the trunk, the 
mortgage check has been written but not mailed, and the leaves are piled up but not 
bagged. You’ve expended effort but haven’t created any value. The value arrives 
when the drop cloths and paint cans are out of the bathroom, the dog has been fed, the 
bank gets its money, and the yard is actually clear of leaves. Doing half of something 
is, essentially, doing nothing. 


As I’ve said, in Scrum there is a rhythm to the work. Every iteration, or Sprint, 
the team tries to get a number of things done. But that “Done” implies a complete, 
deliverable product that can be used by a customer. If something 1s half done at the end 
of the Sprint, you’re worse off than if you hadn’t started at all. You’ve expended 
resources, effort, and time and gotten nothing to a deliverable state. You have a half- 
constructed car. It might have been better to create something smaller—something that 
really works. 


Another way to look at work in process or inventory is simply as physical 
inventory. Let’s take cars, for example. Having tons of cars sitting on a lot unsold is a 
problem for an automaker. But not having cars available to be sold is also a problem. 
So each automaker and dealership operation engages in a careful balancing act. They 
want to produce just enough vehicles to keep stock available, but not so many that 
they’ ve invested huge amounts of money in things that aren’t selling. 


Let me put some actual numbers to that. In December of 2012, General Motors 
started laying off people in some of its auto plants in America. Why? The company 
had built too many cars. At the end of November that year they had 245,853 full-size 
pickups sitting in car lots across the country. That represented 139 days’ worth of 


trucks. At average pricing, those unsold vehicles represented about $7.5 billion. 
That’s billion with a 5. All that money, in this case truck-shaped money, but money 
nonetheless, sitting there unsold. So they started shuttering plants, putting people out of 
work right before Christmas. 


How many days of inventory should a car company work toward? The industry 
standard is about sixty days—less than half what GM had. Think about it. When you 
pick up dog food at the store, you don’t want to purchase a six-month supply. It takes 
up space in the garage and might cost so much money so that the mortgage check won’t 
be able to go out that month. 


Now, you might think, hey, they've bui/t the cars; they’ve got that part done, 
right? They aren’t half-built cars—what’s the problem? The problem is that too much 
inventory is pretty much the same thing as work in process. If you’re tying up a huge 
amount of value in things that aren’t delivering value, you won’t have those resources 
to do other things—such as market more, or push more sales, or explore new ideas. 
You have to have some inventory; the key is to minimize it. 


Jobs that aren’t done and products that aren’t being used are two aspects of the 
same thing: invested effort with no positive outcome. Don’t do it. 


Do It Right the First Time 


Dr. James Womack, the founder of the Lean Enterprise Institute at MIT and the author 
of a bunch of different books on Lean manufacturing, tells a wonderful story about the 
perils of “re-work” in his classic The Machine That Changed the World. Jim and his 
team spent years traveling the world looking at the biggest manufacturing effort ever 
undertaken by humans: making cars. He wanted to figure out why some companies 
made cars faster and with fewer defects than other companies. By now, any rational 
manufacturer uses what Jim decided to call Lean manufacturing, but back then things 
were different. 


One of the biggest differences between manufacturers was in the luxury-car 
market. In Japan, such companies as Toyota, Honda, and Nissan spent an average of 
16.8 hours making a luxury car. Parts went in at one end of the factory, and, about 17 
hours later, a Lexus emerged. And they had 34 defects per hundred vehicles. Not bad. 


In Europe, though, the story was different. Such companies as Mercedes-Benz, 
Audi, and BMW took 57 hours to make a car, and they had 78.7 defects for every 
hundred vehicles. 


Why did it take the Europeans so long? And why so many defects? BMW isn’t 
exactly known for making crappy cars. Here’s why: In a Toyota plant when a problem 
shows up on the line, every worker has the ability to stop the whole line. When that 


happens, everyone swarms around where the line stopped—not to yell at the guy for 
stopping the line, but to fix whatever problem is there. They don’t want any cars 
coming out the other end with things that have to be fixed. They fix the problem once, 
and it’s solved forever. If they don’t, that same defect could go into hundreds of 
vehicles. 


At European luxury-car makers there was a different way of doing things. At the 
end of the production line were dozens of people in white lab coats going around 
fixing all the problems. They made sure the car door had that BMW clunk when the 
door closed, or the engine purred with exactly the right tone. They made sure all the 
parts meshed together properly. They viewed themselves not as manufacturers but as 
craftsmen, artisans making a thing of beauty. That’s great when you’re making a few 
cars, but when you’re making millions, those costs add up. As Womack reports in his 
book: 


... the German plant was expending more effort to fix the problems it had just 


created than the Japanese plant required to make a nearly perfect car the first 
time.® 

You read that right. The Germans spent more time fixing a car they’d just made 
than the Japanese did making one in the first place. There’s a reason Toyota became 
the number one car manufacturer on the planet. They did it right the first time. 


But we don’t always do things perfectly the first time. We’re human; we make 
mistakes. How you deal with those mistakes can have an extraordinary impact on how 
fast you can get things done, and at what level of quality. At Toyota, as I said, every 
worker in the factory can stop the line. The idea is that the process is being 
continuously improved, and that the right moment to fix a problem is when it is 
observed, not after the fact. 


A few years ago I was in California talking to the development people at Palm. 
They made some of the first of what were then called Personal Digital Assistants 
(PDAs), which we now callcell phones. They tracked everything they did 
automatically. One of the many things they measured was how long it took to fix a bug 
—that is, how much time it took asoftware developer to fix a problem he’d 
introduced into the system. The computer tracked this automatically, each and every 
time. 


So let’s say that one day, when the testers tried to integrate Matt’s code into the 
rest of the system, they detected a bug. Matt, like most software developers, wouldn’t 
want to go back and fix that code right away. Instead, he’d vow to get to it later. First, 
he’d write new code. 


At most companies this kind of testing doesn’t even happen on the same day. It 
could be weeks or months before all the code is tested, and only then are the problems 
discovered. But Palm performed daily, automated tests of all their code, so they knew 
right away when there was a problem. 


They looked at the “Matts” across the entire company—hundreds of developers 
—and they decided to analyze how long it took to fix a bug if they did it right away 
versus if they tried to fix it a few weeks later. Now, remember, software can be a 
pretty complicated and involved thing, so what do you think was the difference? 


It took twenty-four times longer. If a bug was addressed on the day it was 
created, it would take an hour to fix; three weeks later, it would take twenty-four 
hours. It didn’t even matter if the bug was big or small, complicated or simple—it 
always took twenty-four times longer three weeks later. As you can imagine, every 
software developer in the company was soon required to test and fix their code on the 
same day. 


The human mind has limits. We can only remember so many things; we can really 
only concentrate on one thing at a time. This tendency—for the process of fixing things 
to get harder as more time elapses—represents a similar limitation. When you’re 
working on a project, there’s a whole mind space that you create around it. You know 
all the different reasons why something is being done. You’re holding a pretty 
complicated construct in your head. Re-creating that construct a week later 1s hard. 
You have to remember all the factors that you were considering when you made that 
choice. You have to re-create the thought process that led you to that decision. You 
have to become your past self again, put yourself back inside a mind that no longer 
exists. Doing that takes time. A /ong time. Twenty-four times as long as it would take 
if you had fixed the problem when you first discovered it. 


I’m sure you’ve had this experience yourself in your own work, and the lesson is 
one you were probably taught as a child: Do things right the first time. The only thing 
the data now adds is that if you do make a mistake—and we all make them—fix it as 
soon as you notice it. If you don’t, you'll pay for it. 


Working Too Hard Makes More Work 


When Scott Maxwell, the founder of the venture capital firm OpenView Venture 
Partners, was working as a consultant at McKinsey & Company in the early 1990s, he 
received what he considered to be an odd pep talk. Jon Katzenbach, then a director at 
the company and now the author of several books and head of the Katzenbach Center 
at Booz Allen Hamilton, gave Scott some advice he never forgot. Jon said that back in 
the seventies, when he was starting out, everyone worked seven days a week at 
McKinsey. That was the culture; that was what was expected. If you didn’t work that 


many hours, you were seen as not pulling your weight, not contributing to the team. 


For religious reasons Jon worked only six days a week. And he noticed 
something. While he was working fewer hours, he was actually getting more done than 
the guys—and they were almost all guys back then—working every single day. Then 
he decided to try only five days a week. And he found that he was getting even more 
done. Work too long, he said, and you get less done. He told Scott that he always 
wanted to drop down to four or even three days a week to see what would happen, but 
he wasn’t sure that the company would accept it. 


Scott and the other young consultants scoffed at the idea at the time. Work fewer 
hours? Isn't that slacking off? But the idea stayed with Scott for years as he moved 
through his career, and as CEO and founder of OpenView Venture Partners he started 
investing in technology companies, some of which were doing Scrum. He heard that 
I'd invented Scrum and lived in the same city, so he invited me to breakfast one 
morning. Over coffee and croissants, Scott told me the story of one of the companies in 
which he’d invested where the development teams had implemented Scrum and how 
they’d improved their productivity 25 to 35 percent. He was really impressed. My 
instant response: “Twenty-five to thirty-five percent? They must be doing it wrong!!!” 


Scott decided to bring Scrum to OpenView and implement it throughout the 
company. The investment guys, the research folk, senior management, the admin staff 
—everyone was put on a Scrum team. And eventually something happened that is one 
of the great things about Scrum—OpenView discovered how people actually work 
instead of how they say they work. 


At that time OpenView was like a lot of high-powered offices. Ingrained in the 
corporate culture was the expectation that people would work late and on the 
weekends. These were aggressive, ambitious people. But they were getting burned 
out, depressed, and demoralized. It was such a tough environment that some people 
couldn’t take it and quit. 


But as the firm’s teams started working with Scrum, Scott noticed a shift in 
productivity. Working more hours stopped producing more output. He pulled me into 
his office one day and drew this curve on a whiteboard (see this page). 


The y-axis is productivity, and the x-axis is hours of work. The peak of 
productivity actually falls at a little bit less than forty hours a week. Armed with this 
data, Scott started to send people home early. 


“Tt took them a while to get that I was serious,” says Scott. “But eventually they 
came around to my way of thinking.” 


He started telling people that working late wasn’t a sign of commitment; it was a 


sign of failure. “It’s not because I want you to have a balanced life,” he told people. 
“It’s because you'll get more stuff done.” 


So no more nights, no more weekends. When people go on vacation, they are 
expected to go on vacation, not check e-mail, not check in with the office. If you can’t 
actually take time off without having to make sure everything is going right at the 
office, the thinking goes, you aren’t managing your teams well. 
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“A lot of companies don’t practice [work-hour limits],” says Scott. “But there is 
a direct correlation. You get more done. You are happier. And you have higher 
quality.” It’s a no-brainer. Working less helps you get more done with higher quality. 


Scott says the curve is different for different people, even for the same person at 
different times in their lives. “Ive noticed as I’ve gotten older and in different roles 
that the peak output for me is at a lower number of hours than it was twenty years 
ago,” he says. Physical fitness, diet, personal issues, and other factors all play a role, 
he thinks. But he also believes that his output reaches its peak faster as he has grown 
and thought quite deeply about how to work. “I’ve been able to attack more and more 
important-impact opportunities.” 


Why is it that if you work fewer hours, you get more done? It doesn’t really seem 
to make sense on the face of it. Scott says that people who work too many hours start 
making mistakes, which, as we’ve seen, can actually take more effort to fix than to 
create. Overworked employees get more distracted and begin distracting others. Soon 
they’re making bad decisions. 


Jon Katzenbach’s instincts were right. The disturbing evidence reveals that we 
have a very limited capability to make decisions, and the more energy-depleted we 
are, and the less downtime we get, the worse we are at it. 


In April of 2011, a group of Israeli researchers published some remarkable 
research about decision making in the Proceedings of the National Academy of 
Sciences of the United States of America. Their paper, titled “Extraneous Factors in 
Judicial Decisions,” looked at over a thousand judicial rulings by eight Israeli judges 
who presided over two different parole boards. The rulings covered Jewish-Israeli 
and Arab-Israeli criminals—both men and women. The crimes ranged from 
embezzlement and assault to murder and rape. The vast majority of the decisions the 


judges looked at were requests for parole.2 


It seems fairly straightforward, right? These are esteemed judges using their 
years of experience and wisdom to make critical decisions affecting not only the lives 
of the prisoners and their victims but the well-being of the community as a whole. 
Each day they heard between fourteen and thirty-five cases. 


So if you were a prisoner, what was the biggest factor in whether you’d go free 
or not? True remorse, perhaps? Your reformation and behavior in prison? The 
severity of your crime? None of those, actually. It turns out what really mattered was 
how long it had been since the judge had had a sandwich. 


The researchers looked at what time judges made decisions, whether clemency 
was granted, and how long it had been since the judges had had a snack. If they’d just 
gotten to work, or back from a snack break, or back from lunch, they made favorable 


decisions more than 60 percent of the time. That rate dropped to nearly zero by the 
time of the next break. 


Basically, right after a short break, judges came in with a more positive attitude 
and made more lenient decisions. They displayed more imagination and capacity to 
see that the world, and people, could change, could be different. But as they burned up 
their reserves of energy, they began to make more and more decisions that maintained 
the status quo. 


I’m sure that if you asked these judges if they were certain they were making 
equally good decisions each time, they’d be affronted. But numbers, and sandwiches, 
don’t lie. When we don’t have any energy reserves left, we’re prone to start making 
unsound decisions. 


This phenomenon has been labeled “ego depletion.” The idea is that making any 
choice involves an energy cost. It’s an odd sort of exhaustion—you don’t feel 
physically tired, but your capacity to make good decisions diminishes. What really 
changes is your self-control—your ability to be disciplined, thoughtful, and prescient. 


A fascinating experiment shows just that. A group of researchers wanted to know 
how making decisions affects self-control. So they gathered the foot soldiers of 
psychological research—collegiate undergraduates—and had one set of them make a 
bunch of decisions. Specifically, these students were presented with different products 
and asked to choose which they preferred. They were told to think carefully because 
they’d be given a free gift at the end of the experiment, and their preferences would 


decide what they’d get. The other set of students had no decisions to make.!2 


The test group was asked questions, such as: What kind of scented candle do you 
like—vanilla or almond? What kind of shampoo brand do you prefer? Do you like this 
kind of candy or that? Then they were given the classic test of self-control: How long 
can you hold your hand in ice water? 


Whatever resource is burned up by making decisions is also used up in self- 
regulation. The students who’d made all the product decisions simply couldn’t hold 
their hands in the icy water as long as the control group that had been spared the 
decisions. 


So there’s a limited number of sound decisions you can make in any one day, and 
as you make more and more, you erode your ability to regulate your own behavior. 
You start making mistakes—eventually, serious ones. As the Maxwell Curve shows, 
those bad decisions impact productivity. So go home at five. Turn off the cell phone 
over the weekend. Watch a movie. Perhaps, most important, have a sandwich. By not 
working so much, you'll get more and better work done. 


Scrum asks those who engage in it to break from the mind-set of measuring 
merely hours. Hours themselves represent a cost. Instead, measure output. Who cares 
how many hours someone worked on something? All that matters is how fast it’s 
delivered and how good it is. 


Be Reasonable 


There are three types of waste identified by Taiichi Ohno that lead to people working 
harder, and for more hours, than necessary. I’ve just pointed out why that’s an 
incredibly bad idea, but recognizing these types of waste, which Ohno called Muri, or 
“Unreasonableness,” is perhaps the most powerful lever for change we can reach. 


The first 1s “Absurdity.” You want to give your team challenging goals—to push 
them to reach for more. But you don’t want them striving for absurd, impossible goals. 


The second is “Unreasonable Expectations.” How many times have you heard 
someone brag that through their own heroic efforts they saved a project? Usually this 
is greeted with backslaps, cheers, and congratulations. I see this as a fundamental flaw 
in the process. A team that depends on regular heroic actions to make its deadlines is 
not working the way it’s supposed to work. Constantly moving from one crisis to the 
next causes burnout, and it doesn’t allow for reasoned, continuous improvement. It’s 
the difference between a cowboy riding in and rescuing the girl from the bad guys and 
a disciplined Marine platoon clearing the kill zone. 


Ohno called the third type of waste “Overburden.” It’s the sort of behavior that 
Scott Adams regularly lampoons in his Dilbert cartoons. It includes onerous company 
policies that get in the way, unnecessary reporting that has people filling out forms for 
the sake of filling out forms, and meaningless meetings that suck up time and don’t 
deliver any value. 


While Ohno didn’t mention a fourth type of waste, one comes to mind—41.e., 
“Emotional Waste.” That type of waste is generated when a company has an asshole in 
its midst—someone who likes spinning up other people and putting them in a tizzy. 
Assholes often justify their behavior by claiming they’re simply trying to make people 
work better. But they’re merely indulging the negative aspects of their personality, and 
nothing is more undermining of a team’s ability to excel. 


Don’t be an asshole—and don’t allow, abet, or accept that behavior in others. 


Flow 


In a theoretically perfect world, there would be no process, no meetings, no forms, no 
reporting. Instead, there’d be the creation of exactly what the customer wants, even if 
the customer didn’t know they wanted it yet. Any “process” that people use is 


wasteful, and that includes Scrum. 


But we don’t live in a perfect world, and bad processes are so ingrained in our 
thinking that, as an alternative, we need the lightest-weight process with the greatest 
impact on work. What Scrum does is focus us on trying to eliminate the pointless 
waste that seems part and parcel of work. I’ve tried to make it so that the process 
itselfis the least disturbing framework you can have and still keep people focused. 


What you really want in your work is effortless “flow.” In the martial arts or in 
meditative practice, when you reach a sense of oneness with a motion, it is no longer 
an effort; it is energy effortlessly flowing through you. When you watch great dancers 
or singers, you sense that they’re surrendering to a force greater than themselves as 
they let their art move through them. Reaching that spot in our work is what we should 
all seek. 


But as the kung fu master, the monk, the dancer, or the opera star will all tell you, 
at the root of flow is discipline. There can be no wasted movement—nothing 
extraneous—just focused application of human capability. Waste is anything that 
distracts you from that. If you start thinking about work in terms of discipline and flow, 
you might just do something amazing. 


THE TAKEAWAY 


Multitasking Makes You Stupid. Doing more than one thing at a time 
makes you slower and worse at both tasks. Don‘? do it. If you think this 
doesn’t apply to you, you’re wrong—it does. 


Half-Done Is Not Done. A half-built car simply ties up resources that could 
be used to create value or save money. Anything that’s “in process” costs 
money and energy without delivering anything. 


Do It Right the First Time. When you make a mistake, fix it right away. 
Stop everything else and address it. Fixing it later can take you more than 
twenty times longer than if you fix it now. 


Working Too Hard Only Makes More Work. Working long hours doesn’t 
get more done; it gets /ess done. Working too much results in fatigue, which 
leads to errors, which leads to having to fix the thing you just finished. 
Rather than work late or on the weekends, work weekdays only at a 
sustainable pace. And take a vacation. 


Don’t Be Unreasonable. Goals that are challenging are motivators; goals 
that are impossible are just depressing. 


No Heroics. If you need a hero to get things done, you have a problem. 
Heroic effort should be viewed as a failure of planning. 


Enough with the Stupid Policies. Any policy that seems ridiculous likely 
is. Stupid forms, stupid meetings, stupid approvals, stupid standards are just 
that—stupid. If your office seems like a Dilbert cartoon, fix it. 


No Assholes. Don’t be one, and don’t allow the behavior. Anyone who 
causes emotional chaos, inspires fear or dread, or demeans or diminishes 
people needs to be stopped cold. 


Strive for Flow. Choose the smoothest, most trouble-free way to get things 
done. Scrum is about enabling the most flow possible. 


CHAPTER SIX 


Plan Reality, Not Fantasy 


“Hey, Jeff, we have a problem.” 


That’s how a lot of my phone conversations start. People have backed themselves 
into a corner, and they pick up the phone and call me. This time it was Mark Landy, 
Medco’s Chief Architect of Software. If you get your prescriptions through the mail, 
you more than likely deal with his company. At the time of this call Medco was a 
Fortune 100 firm with nearly $38 billion in revenue, the largest pharmaceutical 
company in the country, with tens of thousands of employees. And their management 
had just walked them off a cliff. 


I got the call in December of 2006. That July, their president, Kenny Klepper, 
had announced to Wall Street his latest idea. Mark Landy described it this way: “We 
were trying to convince more and more people to switch to getting their prescriptions 
by mail. And there are some barriers to that.” Barriers such as the appearance of 
inconvenience. But Mark said there were some ways around it. “Look, when you go 
into a pharmacy, your experience is minimally clinical. You hand over your 
prescription, sign a waiver saying you don’t want to talk to the pharmacist, and walk 
out. We can improve that experience.” 


One of the things they wanted to do was put a pharmacist on the telephone with 
the patient—a pharmacist who was familiar not only with the drug being described, 
but witha// the drugs being prescribed to that patient. The latter was particularly 
important if the patient had a chronic condition such as diabetes or heart disease, 
which 80 percent of the people on regular medication do. And most of those folks— 
certainly if they’re older—are on six or more medications at the same time. And their 
doctors—specialists in different fields of health—don’t always know it. 


“Doctors don’t [always] share information with each other. We, as the pharmacy, 
know more than the doctors know, and we know it in real time, [even] before the 
health insurance plan knows,” said Landy. 


So here was Klepper’s idea: Let’s create specialized pharmacies in five different 
sites spread across the country. There’ll be the cardiac pharmacy, the diabetes 
pharmacy, the one for asthma, and so on. And we’ll train pharmacists assigned to 
those sites to be aware of drug interactions, side effects, etc. And because the 
pharmacists will have comprehensive insight into the patient’s condition, they’ll be 
able to let doctors know when there might be contraindications. Let’s say someone is 
diabetic. They’re more likely to be overweight and, possibly, to have liver issues. As 
a result they'll metabolize drugs differently. So if a new doctor prescribes a blood 


pressure medication, the Medco pharmacist might call the doctor and recommend that 
he or she run a liver panel on the patient and adjust dosage if need be. 


The goal was to bring new customers to Medco, which, for the most part, served 
companies and health insurance plans. By using these new pharmacies, or Therapeutic 
Resource Centers, customers could save money by cutting not necessarily their 
prescription costs but their overall medical costs, which rise when people either don’t 
take their medications properly or take drugs that interact poorly with one another or 
with that person in particular. What’s more, Medco would guarantee the cost savings. 
If a customer didn’t save the amount of money Medco projected, Medco would pick 
up the difference. 


Wall Street, to put it mildly, /iked this notion. Pretty cool idea, right? Save money 
and provide better health care. More customers, more sales. Win-win. There was only 
one problem. While Klepper had checked with his managers that the idea was 
technically possible, he hadn’t obtained details on how /ong this plan would take to 
implement. The people who would actually make it happen only found out about it 
after their president had promised Wall Street that the new system would be put in 
place on July 7, 2007. Come hell or high water. 


Making that deadline waCs especially important to Medco, because while they’d 
been the first to start automated mail-order pharmacies, they weren’t the only ones, 
and their competitors were hungry. Unfortunately, they had a lot of hurdles to leap. For 
example, much of the software the company relied on to direct their on-site robots was 
badly outdated. In Medco’s five gargantuan plants filled with four thousand 
pharmacists processing prescriptions, robots whizzed about pulling pills while other 
robots handled packaging and mailing, and all those systems had to talk to one another 
with 100-percent accuracy, or someone could die. 


The idea was that Klepper’s brave new plan would give Medco a chance to 
update their aging systems and stay a step ahead of their competitors. It took the 
company nearly six months to figure out that they couldn’t do it on time. Their 
calculations showed that, in the best-case scenario, they’d deliver the system at least 
one year late. Probably more. That’s when they called me. 


Why it took them six months to figure out that they couldn’t do it in time is 
something that bears examination. It wasn’t that they weren’t smart, or didn’t have the 
right teams in place, or even the right technology. It wasn’t that they weren’t working 
hard or being competitive. You don’t get to be the biggest company in your sector 
without doing all that. 


It was because they made a very basic mistake. They thought they could plan 
everything ahead of time. They spent months of effort making the sort of detailed plans 


that seem plausible—that are laid out on pretty charts and include carefully precise 
steps and almost always describe a fictional reality. 


As I’ve said previously, the very act of planning is so seductive, so alluring, that 
planning itself becomes more important than the actual plan. And the plan becomes 
more important than reality. Never forget: the map is not the terrain. 


When a team first sits down to map out a project, there is often electricity in the 
room—a sense of possibility, of new worlds to discover and new ideas with which to 
experiment. It really is one of the best feelings in the world. 


Then comes that moment when inspiration turns to calculation, and some of that 
energy dissipates. People begin pondering: How do we actually get from point A to 
point B? And once we’ve figured that out, how long is it going to take? 


Unfortunately, that calculation phase can be a garbage-in/garbage-out process. 
The people involved may be highly intelligent, and yet they typically won’t realize 
that what they’re feeding into their planning charts 1s a lot of wishful thinking. 


When Mark had explained the situation at Medco, I replied, “You do have a 
problem.” I waited a beat, then followed that with: “But I bet we can solve it.” 


Right before Christmas I flew to New Jersey to spend a day at the company, 
determining the scope of the issue. It was not trivial. There were reams of paper 
outlining requirements, compliance, all sorts of reports and phase-gates and quality 
assurance. Buried in there somewhere was what actually needed to be done, but no 
one actually had a plan for how to do it. 


After meeting with key personnel for a while, I called up Brent Barton, a Scrum 
trainer ’'d worked with on other projects. “Brent,” I said, “I need you and whomever 
else you can wrangle by the beginning of January. We’ve got our work cut out for us.” 


Brent would later describe the Medco he saw when he walked in as a company 
in “deadlock.” There were so many interests and people at loggerheads that nothing 
was getting done. That first day we met with about seven different groups of people, 
each of which owned a piece of the project, and none was really interested in trying 
something new. But, he says now, “We had the luxury of ‘Oh, shit.” You can use pain 
and fear as your ally when you walk in as a consultant. When we ran into resistance, 
we just told them, ‘Hey, you can do things the way you’re doing them, stick with the 
status quo, and you’ll deliver late, and that'll be fine.’ And they said, ‘That’s not 
fine.” ” 


The first thing we did was call everyone into a conference room—all the key 
players, all the people who’d actually be doing the work. And Brent told everyone to 
print out all the documents they had describing what needed to be done with the 


project. No, e-mail wasn’t okay; we wanted physical paper. 


We were ina large room, maybe fifty feet on a side—windowless, as those kinds 
of rooms mysteriously always seem to be. In the middle was a table where we stacked 
all the documents that people walked in with a few hours later. The stack was at least 
two feet tall. 


“How many of you have actually read all this?” I asked. 
Silence. 


“But look,” I said to one of the managers, “you signed off on this. There’s your 
signature. Didn’t you actually read it?” 


More awkward silence. 


I didn’t want to pick on him, but the fact is, in project after project, people cut 
and paste and throw in boilerplate, but no one actually reads all those thousands of 
pages. They can’t. That’s the point. They’ve set up a system that forces them to 
endorse a fantasy. 


So Brent and I got out scissors and tape, glue sticks, and sticky notes. Turns out, 
you really did learn everything you need to know in kindergarten. 


“Here’s what we’re going to do,” Brent said. “We’re going to go through these 
stacks of paper and cut out everything that is actually something that needs to be done 
to complete this project. Then we’re going to stick them on the wall.” 


So over the next couple of hours that’s what people did. At the end we had 
hundreds and hundreds of notes lining three walls. Still on the table was more than 50 
percent of that two-foot tower. Duplication, boilerplate, templates. Complete and total 
waste. 


Then I said to the teams, “Now we need to estimate how much work each one of 
these sticky notes will take.” Not how long, but how much work. 


Pll go into the best ways to do this later in this chapter, since humans are actually 
awful at estimating work. But I taught them a quick and dirty method that is the best of 
a whole bunch of bad ways of doing it, and they went at it. 


It took them a while, but they did it. Up on the wall was everything they needed to 
do to complete the project, broken down into manageable tasks. And they’d estimated 
how much effort they thought each one would take. They actually were excited. An 
unreadable stack of paper had become understandable pieces of work. It’s like that 
old saw, “How do you eat an elephant? One bite at a time.” 


One of the key things we did with each sticky note was write down not only what 


had to be created, but also how we’d know when it was done. This is how we 
incorporated all the FDA compliance requirements, quality assurance, and process 
reports they had to be mindful of. We simply said for this task to be done, it had to 
meet those goals. We baked that into the project at the work-item level, rather than 
waiting for everything to be done and then finding out that we weren’t in compliance 
with some federal regulation or internal quality metric. This way everyone on the 
team, not only the compliance people, had to work to meet that level of quality first, 
before moving on to the next item. The amount of rework this removes from a project 
is incredible. I call this standard that must be met a “Definition of Done.” Everyone 
knows when something is done or not; there are clear standards that any piece of work 
has to meet. 


Staring at all those sticky notes on the wall, everyone had a feeling of 
accomplishment. They could now see what they had to do. 


“Okay,” Brent said. “What do we need to do first?” 
About five people spoke up. 

“And then?” 

Another five people with different ideas this time. 
“And then?” 


What we wanted them to do was something that, at times, no one really wants to 
do: prioritize the work. Often people simply say everything is important. But what he 
was asking was, What will bring the most value to the project? Let’s do those things 
first. 


At the end we had six different rows of sticky notes on the walls, each a different 
color representing a different team. The lists stretched the length of three sides of the 
room. Now I knew we could at least begin. 


Wedding Planning 


It may sound simple when I put it that way, but let me illustrate the steps in the process 
by using an example that is smaller in scale: a wedding. A formal wedding is a project 
with a lot of things that have to be done by a particular date, and as you know, if 
you’ ve gotten married—or will discover, if you do decide to wed—everything will go 
wrong and will take four times the effort you anticipated. 


Of course, it can go the other way too: something that you think will take hours 
gets banged out in fifteen minutes. The ever-plaguing question 1s, Why are we so 
terrible at estimating how long something will take? 


And, boy, are we bad. We’ll get to that wedding in a moment, but first let me 
introduce you to a graph with one of the best names ever, the “Cone of Uncertainty.” 


The graph shows that beginning estimates of work can range from 400 percent 
beyond the time actually taken to 25 percent of the time taken. The low and high 
estimates differ by a factor of sixteen. As the project progresses and more and more 
gets settled, the estimates fall more and more into line with reality until there are no 
more estimates, only reality. 


Think back to Medco. They spent months planning their effort—what the product 
would look like, how long it would take. And even after all those months, the research 
shows that they were likely to be off by as much as a factor of four either way. Which 
is why, in my opinion, Waterfall-type planning is a really stupid way of doing things. 


THE CONE OF UNCERTAINTY 


Variability in 
the Estimate 1.2 
of Project Scope 
(effort, cost, 1.0 
features) 


Time 


Okay, Sutherland, I can hear you saying, we’re bad at estimating, but I’ve got to 
do something, right? I have to have some sort of plan. And you're right: you do. But 
the key is to refine the plan throughout the project rather than do it all up front. Plan in 
just enough detail to deliver the next increment of value, and estimate the remainder of 
the project in larger chunks. In Scrum, at the end of each iteration you have something 
of value that you can see, touch, and show to customers. You can ask them: “Is this 
what you want? Does this solve at least a piece of your problem? Are we going in the 
right direction?” And if the answer is no, change your plan. 


So how do you do it? 


Let’s talk about that wedding. The first thing to do is create a list of all the things 
that make up a successful wedding. It might look something like this: 


¢ Bride and Groom 

¢ Flowers 

* Invitations 

¢ Church 

* Reception Hall 

* Food 

¢ Officiant 

¢ Dress 

¢ Wedding Rings 

¢ Music (DJ or Band) 

Now, the next thing to do is to take all those elements and sort them by priority. 
And that’s going to be different for different people. Every bride and every groom 


sees the world differently. But I asked my friend Alex the other day how he prioritized 
his list, and this 1s the order he came up with: 


¢ Bride and Groom 
¢ Officiant 

¢ Wedding Rings 

* Reception Hall 

* Invitations 

* Food 

¢ Music 


¢ Dress 
¢ Flowers 
¢ Church 


The point of the exercise is to figure out the really important things and work on 
those first. For Alex, the food and music are more important than having the wedding 
in a church or the flowers. This is important data to have, because if you start bumping 
up against date or cost constraints, you know where to start cutting—at the bottom of 
the list. Pll get into more detail on this in chapter eight, but that’s probably enough for 
now. 


At Medco the list wrapped around three walls of a large conference room and 
was hundreds of items long with six different teams working on them. But the concept 
was entirely the same. Organize by value, whatever value that may be. It could be 
business value in the case of Medco, or it could be bride happiness value in the case 
of a wedding. 


Size Does Matter, but Only Relatively 


So you have your list of stuff that needs to be done, and you’ve prioritized that list. 
Now the job is to figure out just how much effort, time, and money the project will 
take. As Pve already pointed out, we humans are absolutely terrible at this, but what 
we are good at, it turns out, is relative sizing—comparing one size to another. Picking 
out the difference between small, medium, and large T-shirts, for example. 


My favorite example ofrelative sizing is “Dog Points.” Several years ago a 
friend and one of the leading figures in Agile thinking, Mike Cohn, was, like me, 
struggling with how to make his projects come in on time and on budget, and how to 
estimate them. A dog lover, though his wife forbade him from getting a pooch, he 
started asking his teams what size of “dog” each piece of a project was. He’d list off a 
bunch of breeds. Like this: 


¢ Labrador retriever 
¢ Terrier 

¢ Great Dane 

* Poodle 

¢ Dachshund 

¢ German shepherd 
* Irish setter 


* Bulldog 


And then he’d say, “Okay, this problem—is it a dachshund or a Great Dane? And 
if that one is a dachshund, this one must be about the size of a Labrador retriever, 
right?” And then the teams would go through all the features they had to develop and 
size them by dog. And then Mike would say, “Let’s give each breed a number value; 
that’ ll be easier. Let’s call a dachshund a one and a Great Dane a thirteen. That would 
make a Lab a five, say, and a bulldog a three.” 


You could do the same thing with the wedding to-do list we just made. Finding a 
venue, well, that’s going to take some research, some pricing information, visiting the 
places. It’s kind of involved. Let’s call it a German shepherd—size problem, a five. 
Bride and Groom? No problem: the two of us just have to show up. That’s a 
dachshund, a one, just a phone call. Invitations, though, that is pretty involved. We 
have to make our list, get your mother’s list, get my mother’s list, pick out the 
stationery, have the invitations printed, hand address them. That’s a big project. That’s 
a Great Dane, a thirteen. Or maybe two Great Danes. And if something is that big, you 
should probably cut it down into manageable pieces. How about we make the 
gathering of the names one project and dealing with the printer another? Those are 
probably both the size of a bulldog, right? Call that a three. The addressing we’ ll call 
a German shepherd, a five. And so on. 


So that’s relative sizing, comparing tasks to one another. Now, we don’t all use 
dogs, unfortunately, but you might have noticed a pattern there in the numbers I 
assigned: 1, 3, 5, 8, 13. Each number in the series is the sum of the two previous 
numbers. It’s called the “Fibonacci sequence,” and there’s a reason we use it. It is 
everywhere. 


Fibonacci Sequence: All Around Us 


¢ The Fibonacci sequence is a pattern where the next number 
in the sequence is the sum of the previous two, é.g., 
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¢ Ubiquitous in natural systems, so humans have millennia of 
experience with it 


The sequence is how nature lays itself out, whether it be in the shell of a nautilus, 
the branches on a tree, the bumps on a pineapple, or the petals of a pinecone. It shows 
up in cauliflower and the curves of the human brain. It’s the same whether you’re 
looking at the curl of a fern leaf or the shape of a galaxy. It’s one of those phenomena 
that, when you think about it, is pretty freaky. 


There’s a name for this phenomenon—it’s called the “Golden Mean” or the 


“Golden Ratio.” We’ve built it into buildings and art. From the Parthenon in Athens to 
the Great Mosque of Kairouan in Tunisia. We’ve used it to decide the size and shape 
of pages in a book and the proportions of playing cards. Humans are just programmed 
to find the ratios attractive. For our purposes, all that’s important to know is that our 
species deeply understands the ratios of the Fibonacci sequence. We know them in our 
bones. 


The numbers in the Fibonacci sequence are far enough apart that we can easily 
tell the difference. It’s easy for people to come down on one side or the other. If one 
person estimates something as a five, and another as an eight, we can intuitively see 
the difference. But the difference between a five and a six? That’s pretty subtle, more 
than our brains can really register. 


It’s fairly well-known in medicine that for patients to report they perceive an 
improvement in a symptom, it has to have been a greater than 65-percent improvement. 
Our minds don’t work in smooth increments. We’re better at perceiving jumps from 
one state to another—and not smooth jumps but jagged ones. 


What using the Fibonacci sequence to calculate task size permits is estimates that 
don’t have to be 100 percent accurate. Nothing will be exactly a five or an eight or a 
thirteen, but using those numbers gives us a way to collect opinions on the size of a 
task where everyone is using roughly the same measuring stick, and in that way a 
consensus is formed. 


Estimating as a group in this manner gives us a far more accurate estimate than 
we could come up with alone. 


The Oracle of Delphi 


So now we know we’re good at comparing one thing to another. And we know the 
best ratio to utilize for the task. But how do we get there? A list of prioritized things to 
do is all well and good, but how do we figure out which story is a five and which is 
an eight; which is a goldie and which is a schnauzer? And even if one person has a 
pretty good idea, how do we make sure her estimates line up with everyone else’s? 
What if she isn’t taking some key factors into account? 


Unsurprisingly, this is not a new problem. People have struggled for decades 
with exactly this. One issue is that different members of the team know different things, 
but another is sometimes called the “bandwagon” effect. You’ ve been in meetings like 
that. That’s when someone comes up with an idea, and everyone starts talking about it. 
And even if you disagreed with it initially, you go along because the group is going 
along. And everyone agrees on a path forward that seems like a really good idea at the 
time but turns out to be a complete failure. And when you probe people about the 


decision, it’s almost always the case that each had some reservations, but they didn’t 
voice them because they figured everyone else was excited. People assume that if 
everyone else is going along with something, their own reservation is silly or 
misinformed, and they don’t want to look stupid in front of the group. Remember, this 
groupthink isn’t an individual failure; this is a human failure. 


In the literature this effect has been explained as an “informational cascade.” As 
Sushil Bikhchandani, David Hirshleifer, and Ivo Welch, the authors of the paper “A 
Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades”’ put 
it: “An informational cascade occurs when it is optimal for an individual, having 
observed the actions of those ahead of him, to follow the behavior of the preceding 
individual without regard to his own information.” 


A great example the authors use is the submission of a paper to a journal. Let’s 
say the first journal’s editor rejects it. Then the writer submits the same article to a 
second journal. That journal’s editor, learning of the first rejection, is more likely to 
reject it. And if there’s a third journal, that editor, knowing of the two previous 
rejections, is even more likely to reject it. People assume other people are making 
sound judgments, even if those judgments contradict their own. This is bad. When 
you’re making a judgment about when you'll likely deliver a multibillion-dollar 
project—or whether you'll get everything done on time for your wedding day—it’s 
critical to apply your own judgment, and use other estimates to improve your own, not 
replace it. 


The other well-known problem is what’s called the “halo effect.” This is when 
one characteristic of something influences how people perceive other, unrelated 
characteristics. This was first empirically studied in 1920 by Edward Lee Thorndike. 
In his classic paper “A Constant Error in Psychological Ratings,’ Thorndike asked 
military officers to rank their soldiers by various qualities—physical, intellectual, 
leadership, personality, and so on. He then looked at how one set of qualities affected 
the rating of another. He found that they correlated too closely. If someone’s physique 
was rated highly, so were his leadership skills. And his intelligence. And his 
character. This research has been supported in follow-up studies over the years, 
confirming that, for example, if someone is good-looking, everyone assumes that 


they’re also smart and trustworthy.2 


But the halo effect extends to much more than mere physical beauty; it can crop 
up anywhere. Researchers point out, for example, that nongovernmental organizations 
(NGOs) are often treated as forces for good even if they aren’t, that car companies 
will create one “halo” car to give a whole line a good impression, and that the Apple 
iPod gave all Apple’s products a veneer of coolness. 


As with the bandwagon effect, people who are focused on the “halo” don’t look 
at actual data—trather, they gravitate toward something that has a positive sheen to it. 
Again, this isn’t a failure of will; this is the nature of people. Fighting it head-on is 
silly—it’s like fighting gravity. 


But you can be clever about it. In the 1950s, the Rand Corporation was asked to 
answer some questions—the terrifying kind that got bandied about during the Cold 
War. Invoking in their terminology the Oracle of Delphi, the priestess who could 
predict the future, Norman Dalkey and Olaf Helmer published in 1963 a blandly titled 
paper, “An Experimental Application of the Delphi Method to the Use of Experts,” 
with the helpful reference “Memorandum RM-727/1-Abridged.” In the paper they 
declared their intention to pose questions without having one person’s opinions affect 
those of another. So they gathered a group of experts: four economists, a physical- 
vulnerability specialist, a systems analyst, and an electrical engineer. And they 
proposed to 


Apply expert opinion to the selection, from the viewpoint of a Soviet strategic 
planner, of an optimal U.S. industrial target system and to the estimation of the 
number of A-bombs required to reduce the munitions output by a prescribed 
amount.4 


Or to put it more simply: the idea was to ask how many nukes the Russians 
needed to stop us from making our own nukes. This was back when a nuclear conflict 
was seen as not only possible, but winnable. 


The thing is, Dalkey and Helmer didn’t want their experts to be influenced by one 
another. What if one was a department head at a big university and another a lowly 
faculty member at a small college? How to prevent one person’s false assumptions 
from spoiling the opinions of others? 


What the two researchers did was conduct a series of anonymous surveys. None 
of the experts knew who the others were; they were just to give their estimates. After 
each questionnaire, the research duo would take the answers—and data relied upon 
for those answers—and feed it back to the group with any identifying characteristics 
stripped away. Rinse and repeat. 


So, in the first questionnaire the number of bombs needed to give a 50-percent 
confidence in the destruction of the US arms industry was estimated to fall in a range 
from 50 at the low end to 5,000 at the high end. When Dalkey and Helmer analyzed the 
answers, it seemed that there were some commonalities in thinking—the vulnerability 
of various targets, the recoverability of various industries, initial stockpiles, and so 
on. They then asked the experts if that breakdown was correct, and what other 


information they used in coming up with their answers. 


And they got back everything from how sturdy the factories were to the difference 
between physical and economic vulnerability to the lead time in manufacturing various 
components. 


Dalkey and Helmer then took that data, gave it to all the experts, and said, okay, 
now how many bombs? Now the range was between 89 and 800. Then they did it 
again. And again. The results kept getting narrower. Eventually the range was down to 
between 167 and 360 nuclear weapons needed. 


Being able to winnow an impossibly wide range of estimates—from 10,000 
percent to about 200 percent—is an incredibly powerful capability for policy makers. 
It allows them to get a general expert consensus without worries of bias. This tool is 
so powerful that it is still used today by Rand. Just one recent example was a 2011 
Delphi exercise looking at the conflict in Afghanistan and estimating the United 
States’s chances of success. The outlook, if you’re interested, was not great. 


Planning Poker 


So the advantage of Delphi is that it takes a broad array of opinions, attempts to 
remove as much bias as possible, and with informed, yet anonymous, statements 
narrows down opinions into a generally accepted estimate. The bad part, for our 
purposes, is that it takes a long time. When I sat down with the teams at Medco, I 
didn’t spend any time with anonymous surveys. I wanted all those hundreds of items 
estimated within hours, not days, and certainly not weeks. 


Fortunately, there is a way of gathering estimates that is fairly quick and accurate. 
It’s called “Planning Poker.” 
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The idea is simple. Each person has a deck of cards with those oh-so-interesting 
Fibonacci numbers on them—1, 3, 5, 8, 13, and so on. Each item that needs to be 
estimated is brought to the table. Then everyone pulls the card they think represents the 
right amount of effort and puts it facedown on the table. At the same time everyone 
flips the cards over. If everyone is within two cards of each other (say a five, two 
eights, and a thirteen), the team just adds them all up and takes the average (in that 
case 6.6) and moves on to the next item. Remember, we’re talking estimates, not 
ironbound schedules. And estimates on small pieces of the project. 


If people are more than three cards apart, then the high and the low cards talk 
about why they think what they do. Then everyone does another round of Planning 
Poker. Otherwise they just average the estimates, which will approximate the numbers 
that the statisticians at the Rand Corporation came up with. 


Here’s an example: Let’s say you’re painting the interior of a house, and you 
need to estimate how long it will take to paint the living room, the kitchen, and two 
bedrooms. And you’re doing this with a team that you’ve painted rooms with before. 
So first the two bedrooms: everyone estimates those at a three. No real disagreement; 
you ve all done this before and see bedrooms as fairly straightforward. Then the team 
estimates the living room. It’s a pretty big room but fairly simple. People’s estimates 
run from five to thirteen, eventually averaging six. Again, no need for discussion. Then 
comes the kitchen, and there’s a three, an eight, a thirteen, and a five on the table. The 
person with the three argues that the room is pretty small, involving even less wall 
space than the bedrooms. The person with the thirteen counters that the real time sink 
is all the taping of cabinets and counters they’ have to do, and that painting all those 
small areas will have to be done with a brush, not with a roller. The team quickly lays 
down new cards. Now the three has become an eight, and everyone else stays the 
same. Close enough, they add them all up, average, and move on to the next task. 


This incredibly simple method is a way to avoid any kind of anchoring behavior, 
such as the bandwagon or halo effects, and it allows the whole team to share 
knowledge on a particular task. It’s crucial, though, that you have the team who’s 
actually doing the work do the estimating, not some expert “ideal” estimators. 


I learned this the hard way when I was working with an e-commerce company in 
Pennsylvania, GSI Commerce. They’ve since been bought up by eBay. What GSI does 
is design the online stores for such companies as Levi’s, Toys “R” Us, Major League 
Baseball, and Zales Diamonds. These are not small projects. And GSI is pretty good 
at it. 


But GSI had the idea, which seemed like a good idea at the time, that instead of 
having each individual team do the estimates, they’d assign the task to the best 
estimators in the company—the smartest guys in the room who really understood the 


projects and the technology and knew what needed to be done. So they took some 
projects and estimated them. This one should take this much time, the next one that 
much, and so on. The plan was to deliver estimates for eighty multimillion-dollar 
projects to both their clients and the teams that would actually do the work. This 
seems reasonable, right? 


Well, it turns out to be such a wrong way of going about things that they stopped 
the experiment halfway through, after forty projects were done. I was reminded of 
those drug studies that are halted because it turns out the drugs are killing the patients 
instead of curing them. The estimates were so far off, they were useless. Nothing was 
delivered on time. Customers were unhappy. The teams were demoralized. It was a 
complete disaster. The managers went back to having the teams that would be doing 
the work also do the estimation. Lo and behold, the estimates once again started lining 
up with reality. 


What I took away from that was that only the people doing the work know how 
long and how much effort it will take. Maybe their team is really good at one kind of 
thing but terrible at another. Maybe they have one expert who can be helpful in a 
particular area, but no one on the team knows about a different area. Teams, as I’ve 
discussed before, are individual and unique. Each has its own pace and rhythm. 
Forcing them into cookie-cutter processes is a recipe for disaster. 


There Are No Tasks; There Are Only Stories 


When you list things that need to be done, it’s tempting just to put together a list as I 
did earlier about Alex’s wedding: church, flowers, officiant, food, etc. The problem 
is, if you give any of those items to a separate team that isn’t intimately invested in the 
results of the decisions between white roses and daisies, you might not get the results 
you're looking for. 


How many times at work have you been given a job where you don’t understand 
the reason you’re doing it? Someone asks you to determine how much sales changed 
from month to month in Region A, looking at stores with more than 600 square feet. 
You do it, but you don’t know why it needs to be done. And because of that, you might 
provide the wrong kind of data, you might misinterpret the question, or you might just 
get resentful at being given a bunch of what seems like busywork. Or if you’re the 
manager, you might be astounded that your people don’t understand immediately that 
you're looking at closing down small stores and opening up big ones. 


The problem is that you’re not getting, or giving, enough information to actually 
do the job right. People think in narratives, in stories. That’s how we understand the 
world. We have an intimate grasp of characters, desires, and motivations. Where we 
get into trouble is when we try to abstract out of the main through-line discrete parts 


and deal with them out of context. 


So the first thing you want to think about when you’re considering a task is 
character or role—for example, a customer, a bride, a reader, an employee. Who is 
this task being done for? Whose lens on the world is the one we need to gaze through 
when we’re building this thing, making that decision, or delivering this piece? 


Then you need to think of the what—what we want done in the first place. This is 
usually where we start and stop. But it’s only the middle of the process we should be 
following. 


Finally, you need to think of motivation. Why does this character want this thing? 
How is it going to serve and delight this particular customer? And, in a way, this is the 
key part. Motivation colors everything. 


My favorite example of this comes from an Internet meme from a few years back. 
It’s simply a picture of Captain Jean-Luc Picard of the USS Enterprise, under which 
the text reads: “As a starship captain, I’d like the log function to automatically use 
today’s stardate.... ” It makes sense when you think about it. Haven’t you wondered 
why in the far future a starship captain would have to state the date when he makes a 
log entry? “Captain’s Log. Stardate 4671.7. The planet Mars is lovely from orbit...” 
We don’t have to do that now when we make a blog entry. Why does he? 


But the key question not answered in that picture 1s why. Why does he want that 
functionality? What purpose will it serve? Is it just to keep entries in date order? Or is 
it more serious? Do those logs have to be unalterable to serve some sort of audit 
functionality by Starfleet crime-scene investigators? Those are two very different 
implementations. One casual, one robust. The team needs to figure out what he really 
wants to do, at which point they might think of a wholly different way to do it, with 
more relevant information that the captain may not have even thought of but that would 
be really useful. 


Often, needs will change with different characters. Imagine, for example, a story 
with the back two-thirds: “... I want a car so that I can drive to work.” Now, if you 
start that sentence with “As a suburban commuter ...” versus “As a farmer in the South 
Dakota Badlands ... ,” you are going to end up with a very different interpretation of 
what the ideal vehicle is. 


So before you prioritize what needs to be done for your business, you need to 
define the character, the user, the customer—the person who’s going to use what 
you’re going to do. You need to know their likes, dislikes, passions, enthusiasms, 
frustrations, and joys. And then you need to understand their motivations. How do 
those character types feed what they want? Why do they need a car? What are they 
going to do with that captain’s log? 


This will also influence how you'll estimate things. Oh, they want a simple 
calendar function; that’s easy. An unalterable time stamp for legal purposes—that’s a 
bit trickier. 


Write Short Stories 


When you’re writing your stories, though, you want to make sure that they’re small 
enough that you can actually estimate them. Imagine the story about Amazon.com: As a 
customer, I want the worlds biggest online bookseller so that I can buy any book I 
want at any time I want. Now, that certainly encapsulates Amazon, but it’s really too 
big to actually do anything with. You need to break it down. Really down. 


You might write stories like these for an online bookstore: 


““As a customer, I want to be able to browse books by genre, so that I can find the 
type of books I like.” 


“As a customer, I want to put a book into a shopping cart, so that I can buy it.” 


“As a product manager, I want to be able to track a customer’s purchases, so that 
I can market specific books to her based on past purchases.” 


Those stories are ones that a team can wrap its head around. A discussion can 
actually ensue about how to implement them. They’re specific enough to be actionable 
but don’t prescribe how they’re going to be done. Remember, the team decides how 
the work will be accomplished, but what will be accomplished is decided by business 
value. The whole collection of stories that might make up that idea of an online 
bookstore is often referred to as an “Epic”—a story too big to do by itself but that 
includes a number of smaller stories that add up to a single idea. 


Tim Stoll is one of those guys whose career spans what might be called a “broad 
spectrum of events,” with a focus on getting teams to get things done fast. He was a 
Special Forces medic who saw service in Iraq and Afghanistan, a CIA contractor, and 
a police officer whose job it was to go after violent felons, and he’s now a Scrum 
coach. He’s always been a Scrum coach, he says, even when he was leading Special 
Forces missions. 


“In Special Operations,” he says, “we don’t call them stories. We call them 
Courses of Action. But they’re the same thing.” 


Here’s one of the few stories Tim can tell publicly about a Special Forces 
mission—a medical mission to Laos. “We had two Epics. The first was a medical 
course of instruction—training local forces on combat medicine. The second epic was 
a de-mining operation dealing with unexploded ordnance.” 


As the medic, Tim was in charge of that first Epic. He says that before the 
mission he sat down and figured out what he needed to accomplish and how he should 
order the substories. And, he says, he started with ideas that fall very easily into the 
Scrum framework. 


“As a Special Forces medic, I must teach basic physiology to my students, so 
they can understand the human body.” 


Tim says that he knew he had to start there as he began writing his stories. His 
students had to understand where the bones were to do any sort of first aid. “First, ’d 
teach long bones, then short bones, then wrists, ankles, tendons, ligaments.” Only after 
the basic stories were covered could he get into setting those bones, clearing airways, 
and stopping bleeding. 


After writing those stories he could see what he needed to support his teaching 
objectives. He needed a skeleton. He needed handouts in English and Laotian. And 
then he broke everything into iterations or Sprints. “Two days flying to Laos. One 
week of setup. Then two six-week iterations on instruction. We had to bring our 
students up from basic to EMT intermediate. And we did it.” 


Be Ready and Be Done 


When you’re writing stories or making a list of work to be done, it’s important to ask 
two questions: Is the story ready? And how will you know when it’s done? 


Let’s take Tim’s story as an example: 


As a Special Forces medic, I must teach basic physiology to my students, so they 
can understand the human body. 


There is a mnemonic I always use to tell whether a story is ready. It was created 
by Bill Wake, who’s a deep thinker on software design. Bill says that for any story to 
be ready it needs to meet the INVEST criteria: 


Independent. The story must be actionable and “completable” on its own. It 
shouldn’t be inherently dependent on another story. 


Negotiable. Until it’s actually being done, it needs to be able to be rewritten. 
Allowance for change is built in. 


Valuable. It actually delivers value to a customer or user or stakeholder. 
Estimable. You have to be able to size it. 


Small. The story needs to be small enough to be able to estimate and plan for 


easily. If itis too big, rewrite it or break it down into smaller stories. 


Testable. The story must have a test it is supposed to pass in order to be 
complete. Write the test before you do the story. 


So Tim’s story is independent; he can accomplish his mission without having to 
consider, say, the helicopter fuel it will take the students to get to the site. His story is 
negotiable: teaching physiology is the story he thinks he needs to do, but if he gets 
there and finds out that the students already have this knowledge, or part of this 
knowledge, he can change his teaching approach. It’s valuable: the students will learn 
practical and applicable knowledge of the human body. It’s small: it’s basic anatomy, 
not how to do surgery given the amount of anatomy he will be teaching. And it’s 
testable: he knows the information he wants to impart, and he can give his students a 
test to see if they’ve actually learned the information. 


For each story pursued there should be both a “definition of Ready” (as in “Does 
it meet the INVEST criteria?”) and finally “a definition of Done” (as in “What 
conditions need to be met, what tests need to be passed, to call it a wrap?’”’). We find 
in real projects that if stories are really Ready, the team will double the speed of 
implementation. And if the stories are really Done at the end of a Sprint, teams can 
double speed again. This is one of the tricks needed to get twice as much work done in 
half the time. 


Sprint Planning 


In Scrum this kind of planning happens with each and every Sprint at what is called the 
“Sprint Planning” meeting. Everyone gets together and looks at the list of stories that 
have to be done and says, “Okay, what can we accomplish at this Sprint? Are these 
stories ready? Can they be done by the end of this iteration? Can we then demo them to 
the customer and show real value?” The key to answering those questions lies in just 
how fast the team is going. 


Know Your Velocity 


We can finally start answering the question as to when things will be done, because 
we now know how to measure what the team 1s actually doing. We have all these 
stories—these things that need to be done. And we’ve estimated them—this one is an 
eight, this one a three, and so on. And then we start on our first Sprint. Let’s say it’s a 
week long. At the end of the week we count up all the stories we’ve completed, total 
the points they were estimated at, and that number tells us how fast the team is going, 
their velocity. And once you have a velocity, you can look at how many stories you 
have left and how many points they represent, and then you know when you’! be done. 


Also once you have your velocity, you can figure out the most important thing in 
Scrum: what is keeping you from going faster? What is keeping you from 
accelerating? In the last chapter I talked about waste, about the things that will slow 
you down. This is how you see if you really are getting rid of waste. 


Let’s go back to Medco, where we started this chapter. After we’d estimated all 
the work, I sat down with the senior management responsible for the project. There 
were several VPs who were general managers of business units and a Senior VP. 


We sat down at the conference table, and that Senior Vice President had only one 
question. “Will you meet the original date?” he asked, slapping his hand on the table. 


“T don’t know,” I said. “But we’ll beat the revised date your people came up 
with, or you can get your money back.” 


“That’s not good enough! Will you meet the original date?” 


“T can’t tell you that today. We have to get the teams moving to see how fast they 
are. P’Il tell you what: in six weeks I'll give you our delivery date, and it isn’t going to 
be one you'll like. But,” I said quickly before he could interrupt, “Ill give you a list of 
the things that are getting in your teams’ way, that are stopping them from meeting that 
July date you promised Wall Street. A list of impediments. And your job will be to 
remove them as fast as possible.” 


He laughed. “Impediments! No problem, Jeff. I used to work at Toyota.” 
I laughed and said, “This looks like a good project already.” 


I knew that he’d embraced Tatichi Ohno’s taxonomy of waste and understood 
how things worked—that getting rid of waste was the key to accelerating teams. 


And so after three Sprints of measuring velocity, the teams had accelerated from 
20 to 60 points per sprint and I knew when the teams would likely deliver. Given the 
velocity of the teams, and we were now at the beginning of March, it would take them 
another nineteen two-week Sprints—December 1. 


Management wasn’t happy. Not good enough. It was July 1 or nothing. Everything 
was riding on it. 


Then I handed them a memo with a list of twelve impediments on it. They ranged 
from not empowering people to make decisions to onerous technical requirements, 
from people not showing up for meetings to simple things such as not having 
everybody on a team work in the same room. There were process, personality, and 
procedure problems—the type of things that are endemic to any corporation. 


These kinds of impediments can seem insurmountable. How often have you 
looked around at your own workplace and thought, We do it this way, we’ve always 


done it this way, and everyone knows its dumb. But for some reason people see 
corporate-cultural change as impossible. I used to agree with them, especially when it 
came to big companies with an ossified culture and policies. 


Medco proved me wrong, and I’Il never go back to my old way of thinking. That 
Senior Vice President from Toyota sent out our memo to his entire staff on a Monday. 
Each impediment had a manager’s name next to it. And each one of the impediments 
was gone by Thursday. Maybe to be motivated to change, people sometimes need a 
gun to their head, but it showed what can be done if the will is there (or if you have a 
guy from Toyota in charge). Nothing is written in stone. Question everything. 


By the end of the next Sprint, the teams’ velocity had gone up 50 percent. The 
new date for delivery was September 1. Still three months late even though they had 
accelerated from 20 points to 90 points per Sprint, over 400 percent! 


And still not good enough. 


So Brent and I gathered everyone together, from engineering to marketing to 
business analysts to compliance folks to management. And they were afraid. They 
were afraid for their jobs and careers if they couldn’t pull this off. So, I asked them 
three questions: 


1. Is there anything we can do differently to speed things up? 

“Well,” said the head of engineering, “during the middle of the last 
Sprint the IT security guys shut off a port to the Internet, so our teams in 
India and Brazil couldn’t get anything done.” 

“Well, we should fix that, shouldn’t we?” I said in disbelief. The head 
of engineering looked at the head of IT, who was sitting farther down the 
table. They thought that might knock another month off the time it would take 
to deliver the product. Two months to go. 

2. Can we offload some Backlog items? Is there stuff we can get other teams to 
do? 

No one had any good ideas. 

3. Can we not do some things? Can we reduce the scope of the project by any 
amount? 

Originally, they told me no way, that they’d already cut to the bone on 
requirements. Okay, I said, but let’s just spend the afternoon whittling away 
at it. Every single task has to fight for its life. 


It took a few hours, but we got another month off delivery. 


That’s when I said, okay, we’re still a month off the date. If we can’t figure out 
something else, we’re going to need to tell management we can’t do it. 


“No,” everyone replied, “we’ll all get fired. Let’s take a look at those three 
questions again.” I proposed we meet with the management team. It was not just our 
problem. It was their problem as well, and they could help. 


It was a short meeting. Management looked at the situation and said, “Well, we 
have to deliver on July 1. Maybe we could just roll it out to one factory first? One 
center? Or only a couple? Would that work?” There was some hemming and hawing 
and rearranging of a few things. But they eventually figured out that they could reduce 
the features needed and meet the July 2007 date the president had promised Wall 
Street. 


At the end of that meeting the Senior Vice President simply said, “Let’s declare 
victory. Call us if you run into any problems.” 


It was amazing to watch the stock price of Medco that summer. When we started 
building the infrastructure, the stock started going up, and when we delivered, it 
continued to rise. How much? Well, many billions of dollars’ worth, from a price of 
25 to over 50 within the year. Wall Street had decided the company would continue to 
grow, would attract new customers, and would maintain its leadership in the field. In 
retrospect, I should have asked for a percentage-of-market-cap increase rather than a 
simple fee. 


A few years later Medco used Scrum to build what they called “Medco 2.0.” 
They restructured every part of the company, from the steel out. New factories, new 
robots, new processes, more automation. Mark Landy, who by then was the Chief 
Technical Officer of the company, says that without the Therapeutic Resource Center 
experience they couldn’t have done it. “They wouldn’t have allowed us to do it 
enterprise wide. But we had the confidence of the entire organization: Development, 
Operations, Finance, Clinical. We were able to make a new culture.” And that, he 
says, is the most important part of Scrum: it changes the culture people work in, which 
can be scary for some. Indeed, the company had to get rid of employees who couldn’t 
make the switch, he says—not because they were incompetent, but because they were 
hoarding information and knowledge for their own benefit, to ensure their own 
indispensability rather than helping the team and the company. Changing that culture, 
though, is what allows true excellence to emerge. 


THE TAKEAWAY 


The Map Is Not the Terrain. Don’t fall in love with your plan. It’s almost 
certainly wrong. 


Only Plan What You Need To. Don’t try to project everything out years in 
advance. Just plan enough to keep your teams busy. 


What Kind of Dog Is It? Don’t estimate in absolute terms like hours—it’s 
been proven that humans are terrible at that. Size things relatively, by what 
breed of dog the problem is, or T-shirt size (S, M, L, XL, XXL), or, more 
commonly, the Fibonacci sequence. 


Ask the Oracle. Use a blind technique, like the Delphi method, to avoid 
anchoring biases such as the halo effect or bandwagon effect or just plain 
stupid groupthink. 


Plan with Poker. Use Planning Poker to quickly estimate work that needs to 
be done. 


Work Is a Story. Think first about who’ll be getting value from something, 
then about what it is, and then why they need it. Humans think in narratives, 
so give them one. As an_X, I want Y, so that Z. 


Know Your Velocity. Every team should know exactly how much work they 
can get done in each Sprint. And they should know how much they can 
improve that velocity by working smarter and removing barriers that are 
slowing them down. 


Velocity x Time = Delivery. Once you know how fast you’re going, you'll 
know how soon you’! get there. 


Set Audacious Goals. With Scrum it is not that hard to double production 
or cut delivery time in half. If you do it in the right way, your revenue and 
stock price should double as well. 


CHAPTER SEVEN 


Happiness 


People want to be happy. Not happy in a complacent, sheeplike way, but in a way that 
is more active. Thomas Jefferson, among many others, extolled the kind of happiness 
that comes from a pursuit. Pursuits do seem to be what make us happy. Scrum done in 
the right way will make workers, customers, managers, and stockholders happy 
(usually in that order). 


Real happiness doesn’t come easy. I met a mountain climber once who sold me a 
photo of the top of the Himalayas as the sun was setting. He took it shortly after he 
reached the peak of Mount Everest solo too late in the day. It seemed impossible to get 
back to base camp before dark. If he didn’t, he was certain to freeze to death. The 
poignancy of the photo reflected his feelings as he wrote what he thought might be his 
last note, that he was happy to have achieved the peak despite the fact that whoever 
may read the note might find him dead. 


If you speak to mountain climbers about an expedition, they won’t spend much 
time talking about the experience of summiting a peak. Instead, they’ll talk about the 
frigid temperatures, the painful blisters, the bad food, the crappy conditions, and the 
balky equipment. And they’ll tell you that, after the elation of reaching the summit, 
there’s usually a letdown (unless the near-death experience continues). They’ve done 
it. Their struggle has achieved something. But if you ask them when they were 
happiest, they’ll tell you it was in those moments of trial—of pushing their bodies, 
minds, and spirits to the limit. That’s when they were the happiest, when they 
experienced true joy. And that’s what they want to experience again. On the face of it, 
no sane person would voluntarily put herself through that kind of thing twice. Yet 
climbers seem unable to stop themselves, challenging peak after peak, seeking joy in 
pursuit of the next summit. 


What’s fascinating is that most cultures are not set up to reward and encourage 
that specific type of happiness. Professor Tal Ben-Shahar taught the most popular 
course at Harvard University, “Positive Psychology.” In his book Happier, Ben- 
Shahar writes: “We are not rewarded for enjoying the journey itself but for the 
successful completion of a journey. Society rewards results, not processes; arrivals, 
not journeys.” 


But our day-to-day life is mostly made up of journeys. We don’t summit peaks 
every day, or make the big score, or get a big bonus. Most of our days are taken up 
with striving toward our goals, whatever they may be. In a company, the goal may be 
to deliver that next great product, or make people’s lives a little better with it, or 


solve some problem that vexes the world. But if we get rewarded only for results, not 
processes, we’re going to be pretty miserable. 


When I first left academia for the business world in the early 1980s, I was put in 
charge of dozens of computer programmers who were miserable. Their projects were 
always late and over budget—and that’s when the projects worked at all. Their mood 
became so negative that the energy in the room brought everyone down. The process 
they used was so broken, it was impossible to succeed. I’ve spent the last thirty years 
addressing that type of problem. 


The importance of happiness really hit me when I was setting up my first Scrum 
team. I realized that I had to address the team’s emotional state as well as its mental 
state. For a West Point-trained fighter pilot, this was something of an adjustment. I 
was used to things being cut-and-dried. Being clinical and scientific, it took me some 
time to figure out that to empower people, to change their lives for the better, I had to 
change myself. Over the course of that first Scrum effort I realized that true greatness 
is deeply rooted in joy. And that to be joyful is to take the first step toward success. 


If all that sounds a little New Agey, or as if I’m about to tell you to sit around a 
campfire and sing “Kumbayah,” you should know that in my early days of advising 
start-ups, the venture capitalists I worked with thought I was a flower child from San 
Francisco. Empowering people would never work in their worldview. Of course, 
these days I'ma senior consultant to venture firms and I’m often treated like an oracle. 
When people have a hard problem, they ask the oracle for the solution. They don’t 
necessarily expect the answer to make sense. They just try it, and, to their surprise, it 
almost always works. 


That’s because happiness is crucial to your business and is actually a better 
forward predictor of revenue than most of the metrics your CFO provides. In this 
chapter I’m going to lay out just how important happiness is to your bottom line, and 
how to capture, measure, and apply it. This is happiness with rigor. 


I may have become a better person through developing Scrum, which makes my 
family and me happier. But as a businessman and a scientist, I like hard data. 


Happiness Is Success 


The research is startlingly clear. Happy people simply do better—at home, at work, in 
life. They make more money, they have better jobs, they graduate from college, and 
they live longer. It’s quite remarkable. Almost universally they’re just better at what 
they do. 


Happy people sell more stuff, make more money, cost less, are less likely to 
leave their jobs, are healthier, and live longer. Or as a 2005 paper that did a meta- 


analysis of some 225 papers with over 275,000 participants put it: 


Happiness leads to success in nearly every domain of our lives, including 
marriage, health, friendship, community involvement, creativity, and, in 


particular, our jobs, careers, and businesses. 


The meta-analysts showed that people who felt happy were more likely to secure 
job interviews, be evaluated more positively by supervisors, show superior 
performance and productivity, and be better managers. 


Here’s the really interesting part, though. It intuitively makes sense that happy 
people do better—it’s because of their success that they’re happy, right? Wrong. From 
that same meta-analysis: “Study after study shows that happiness precedes important 
outcomes and indicators of thriving.” 


That’s right. People aren’t happy because they’re successful; they’re successful 
because they’re happy. Happiness is a predictive measure. And performance 
improves even if people are only a little bit happier. You don’t have to change 
someone’s life dramatically to make them happier, at least temporarily. Even just a 
little bit of happiness leads to markedly better outcomes. People don’t have to be 
deliriously, wedding-day happy, just a little bit happier than they were. Of course, 
making them even happier has an even greater effect. But the message I want you to 
take away from this is simple: even small gestures can have great impact. What 
Scrum is focused on is taking those small things and systematically building them up 
into a scaffolding for success. Just one thing at a time, and you can actually change the 
world. 


I’m going to give you a tool kit to measure your happiness and the happiness of 
your team, company, and family, as well as any organization you happen to be 
involved with. That is what Scrum does. Forget trust-building exercises, and instead 
build trust every single day. And I want you to measure it. It’s not enough to think 
people are happy. I want you to be a scientist about it: quantify it and equate it with 
performance. If something doesn’t match up, there’s a problem. It’s great to go to the 
pub with your team and bond. But it doesn’t do the company a lot of good if that 
bonding doesn’t actually translate into better performance. There are a lot of people I 
hang with just for fun. With my team I want that social aspect to move directly into 
performance. And it does. 


Quantifying Happiness 


How do we make ourselves, our employees, and our fellow team members happy? 
How do we channel that happiness into greater productivity and revenue? 


To answer those questions, I need to take you back to Toyota and Taiichi Ohno’s 
crusade to eliminate waste. That goal led him to the idea of “continuous 
improvement.” It isn’t enough to reach a certain level of productivity and stay there; 
the idea is to constantly examine your processes so as to improve them constantly and 
forever. Perfection can never be reached, of course, but every increment in that 
direction counts. 


Just as work needs to be broken down into manageable chunks and time needs to 
be broken down into manageable pieces, improvement needs to be sliced to a step at a 
time. In Japanese the word used is kaizen, or “improvement.” What is the little 
improvement that can be done right away that will make things better? 


In Scrum this is captured at the end of each Sprint in what I call the “Sprint 
Retrospective.” After the team has shown what they’ve accomplished during the last 
Sprint—that thing that is “Done” and can potentially be shipped to customers for 
feedback—they sit down and think about what went right, what could have gone better, 
and what can be made better in the next Sprint. What is the improvement in the process 
that they, as a team, can implement right away? 


To be effective, this meeting requires a certain amount of emotional maturity and 
an atmosphere of trust. The key thing to remember is that you’re not seeking someone 
to blame; you’re looking at the process. Why did that happen that way? Why did we 
miss that? What could make us faster? It is crucial that people as a team take 
responsibility for their process and outcomes, and seek solutions as a team. At the 
same time, people have to have the fortitude to bring up the issues that are really 
bothering them in a way that is solution oriented rather than accusatory. And the rest of 
the team has to have the maturity to hear the feedback, take it in, and look for a 
solution rather than get defensive. 


The Retrospective meeting 1s the “Check” part of Deming’s Plan-Do-Check-Act 
cycle. The key is getting to that “Act” step, that kaizen, which will actually change the 
process and make it better the next time. It’s not good enough merely to share how you 
feel; you need to be able to act. 


The best way I’ve found to capture all this is with what I call the “Happiness 
Metric.” It’s a simple but very effective way of getting at what the kaizen should be, 
but also which kaizen will make people the happiest. And I’ve used it with pretty 
remarkable results. 


Here’s how it works. At the end of each Sprint each person on the team answers 
just a few questions: 


1. Ona scale from 1 to 5, how do you feel about your role in the company? 
2. On the same scale, how do you feel about the company as a whole? 

3. Why do you feel that way? 

4. What one thing would make you happier in the next Sprint? 


That’s it. It can be done in just a few minutes. Every person on the team takes a 
turn, and it sparks really insightful conversations. Together the team usually comes up 
with a kaizen quite quickly. The method exposes what is most important to each team 
member, and what they think 1s most important for the company. 


And here’s the crucial piece. The team takes that one top improvement and makes 
it the most important thing to do in the next Sprint—with acceptance tests. How can 
you prove you’ve made that improvement? You need to define what success is in a 
concrete, actionable way, so that in the next Sprint Retrospective it’s really easy to 
see if you achieved the kaizen. 


A couple of years ago I decided to expand my company, Scrum, Inc., into a full- 
service Scrum consultancy. We tracked our velocity and found we were finishing 
about forty points of stories every one-week Sprint. When I implemented the 
Happiness Metric, the first thing that emerged was that our user stories weren’t good 
enough. They weren’t ready enough, they didn’t have a definition of Done, and they 
were too vague. I worked on it, and we started to get better stories. During the next 
Sprint, the user stories still weren’t good enough. Our Happiness numbers reflected 
that. In the third Sprint, another issue emerged. We addressed it. And so it went. In just 
a few weeks our velocity accelerated from forty points per sprint to 120. We tripled 
productivity simply by asking what would make people happier. As a result, our 
customers were happier, and our revenue dramatically shot up. All I had to do was 
start asking the team, “What would make you happier?” and then deliver on it. 


We graphed this data over time and saw some extraordinarily interesting things. 
As a CEO, I’m focused on what’s going to happen in the future to our revenue, growth, 
and productivity. Unlike with financial metrics, ve found the Happiness Metric to be 
predictive. Financials look at what happened in the past, but when you ask people 
how happy they are, they actually project into the future. And when they think about 
how happy they are with the company, they start projecting out how they think the 
company is doing. As a result, you'll get indications before a problem arises that one 
is coming. And if you pay close enough attention to what your team is telling you, you 
can take action and fix the issue before it becomes a problem. In the graph on this 
page, for instance, a drop in happiness precedes a drop in velocity or productivity by 
weeks. If you were only looking at productivity, you wouldn’t know that there was a 
problem until it dropped off a cliff. But if you see a team-wide drop in happiness, 


even as productivity is increasing, you know you have an issue that you need to 
address, and soon. 


Make Everything Visible 
What are the things that actually make people happy? They’re the same things that 


make great teams: autonomy, mastery, and purpose. Or to say it more expansively, it’s 
the ability to control your own destiny, it’s the feeling that you’re getting better at 
something, and it’s knowing that you’re serving something bigger than yourself. But 
there are also some easy, concrete steps management can take to get the culture of the 
company to encourage those qualities. 


One element of Scrum that’s often a prelude to achieving autonomy, mastery, and 
purpose is transparency. The idea is that there should be no secret cabal, no hidden 
agendas, nothing behind the curtain. Far too often in a company it isn’t really clear 
what everyone is working on, or how each person’s daily activity advances the goals 
of the company. 


When I was starting Scrum, I spent a lot of time thinking about the laws a good 
friend of mine was influential in introducing into the Colorado legislature 
—‘Sunshine” laws. They require that all public meetings be open, all records be 
available to the public, and that there be nothing taking place behind closed doors— 
nothing hidden. That’s why in Scrum anyone can go to any meeting. Any stakeholder 
can observe a Daily Stand-up or attend a Review. 


What I wanted to do was to make everything visible. And this can be scary to 
some people. Patientkeeper is a company that develops handheld applications for 
hospitals and doctors. When I was hired into the company, I immediately made all of 
engineering a Scrum shop. I told the developers that everyone would know everything. 
They were so used to seeing measurements getting used to beat them up that the new 
level of transparency made them afraid they’d only be abused more. 


“Trust me,” I said. “This won’t be used to hurt you. Or punish you. It will only be 
used to make things better.” 


As I’ve said before, I’m not very interested in individual performance; I’m only 
interested in team performance. I can double a team’s productivity in a month, but an 
individual? That could take a year. And a whole bunch of individuals? A whole 
division? A whole company? That could take forever. So I use transparency to focus 
on improving the team. I find that the team itself usually can address individual 
performance issues. They actually know what people are doing, who is helping, who 
is hurting, who makes the team great, and who makes it painful. 


So in Scrum, everything is visible. In my companies, every salary, every 
financial, every expenditure is available to everyone. I’ve never understood why 
anyone would want to keep this stuff secret except to further their own individual 
agenda, or to keep people infantilized. I want the administrative assistant to be able to 
read the profit-and-loss statement and to understand precisely how what he does 
contributes to that. I want everyone in the company to be aligned with a unified 


purpose. Atomizing people into informational silos simply slows everyone down. 
Plus, it breeds suspicion and distrust. It divides a company into the big boys who 
know stuff and the peons who merely execute segments of some mysterious agenda 
they aren’t capable of understanding. Bullshit. If you can’t trust the people you’re 
hiring to be on board with what you’re doing, you’re hiring the wrong people, and 
you ve set up a system that has failure built in. 


The most dramatic visual representation of this idea, and one you'll see in every 
Scrum team room across the planet, is the Scrum board. 
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Now, there is software out there that can measure all sorts of things, give you all 
sorts of metrics and analysis, but a Scrum board is just a bunch of sticky notes on a 
whiteboard. There are three task-status levels: To Do, Doing, and Done. When 
someone signs out a story, everyone knows who’s working on it. And everyone knows 
when it’s done. And because the board has sticky notes that represent everything that 
needs to be done in a single Sprint, everyone knows how the Sprint is going. Anyone 
can walk into the room, glance at the board, and know exactly how the team is doing. 


Because the team knows what has been done and what still needs to be done, they 
can regulate themselves. They know what they have to do, they can see if a colleague 
is in trouble, if a story has been in the Doing column too long. The team can self- 
organize to defeat problems that become obvious once everything is transparent. 


At PatientKeeper the transparency that those developers were initially wary of 
paid off. Because all the work was transparent, we were able to coordinate 
assignments across multiple teams. Everyone knew exactly what everyone else was 
working on all the time. They could support one another if someone ran up against a 
roadblock. One developer might have already come up with a solution to a problem 
another developer faced, even if they weren’t on the same team! Productivity at 
PatientKeeper increased more than four times. We released a production version of an 
enterprise software product forty-five times a year. This isn’t Angry Birds updating; 
this is stuff deployed at major hospitals that people’s lives depend on. But because we 
were transparent with everything, we could get the product into the market faster than 
anyone in the world. That’s what Sunshine can do. 


After I left PatientkKeeper, a new management team decided Scrum wasn’t the 
best way to run things anymore. The result? Product releases dropped from forty-five 
a year to two, revenue dropped from fifty million dollars a year to twenty-five, and 
attrition, which had been less than 10 percent, shot up to over 30 percent. They went 
from a great company back to mediocre performance by returning to traditional 
corporate behavior. 


Delivering Happiness 


One company that views happiness as core to their culture is Zappos. The wildly 
successful website convinced people to do something a lot of folks thought couldn’t be 
done: buy shoes over the Internet. CEO Tony Hsieh wrote a book about it, Delivering 
Happiness. Tony writes about the unique culture at Zappos, which is based on 
creating “Wow!” moments for customers. It turns out that to make customers happy, 
you want happy people on the other end of the phone. 


In talking to executives at Zappos, one of the words you hear a lot 1s connection. 
Their research shows that the more connected people are to other people at work, the 


happier they are—and, apparently, the more productive and innovative as well. So the 
company execs have set out deliberately to create these connections—not only on one 
team, or in one department, but across the whole company. And not just between 
people at one level, but between different levels, everyone from VPs to Accounts 
Receivable clerks. 


They do this through means both simple and complex. For example, they 
physically encourage chance encounters. Their building has many exits, but they’re all 
closed, save one, forcing people to go in and out through one door. The idea is that by 
having people bump into one another, they’Il more likely create, and nurture, those 
connections. 


Another example relates to the way people are brought into the Zappos culture. 
Each employee, froma warehouse worker to a director, has to go through what Christa 
Foley, the Senior Manager of Human Resources at Zappos, calls “boot camp.” For 
four weeks each employee is brought up to speed on how the company works, but also 
on how the company’s culture works. It is really the second screening within the 
Zappos hiring process. Even after getting the job offer, you have to prove that you can 
absorb the culture. 


The results, says Foley, are remarkable. “Those connections [employees] made 
during boot camp stay with them throughout their careers.” Boot camp 1s purposefully 
intense—people have to show up at 7:00 a.m., work hard, meet deadlines, and pass 
tests. But it works. People who go through boot camp stay connected, not just for 
months but for years, organizing their own reunions and barbecues to stay in touch. 


“Tt becomes an extended family,” says Zappos executive Rachel Brown. “You 
take your work friends home with you. You hang out with them.” 


Another way that Zappos keeps people happy is by giving employees a chance to 
learn and grow. The company almost always prefers to hire internally. Say a job in 
HR is posted, and someone in accounting, who has always thought he might like that 
kind of work, sees it. That person who is curious about HR might then be brought into 
an “apprenticeship.” It gives the employee the chance to see if he really does like that 
work, and it gives the manager a chance to see if he’d make a good fit with the team. 
The company also offers free classes taught by other employees—Finance 101, 
Coding for Beginners, whatever. Zappos wants people to grow at and within the 
company. 

As I mentioned in chapter three, on teams, people want to grow; they want to get 
better at what they’re doing and find what else they can get better at. The idea 1s that 
mastering work motivates people. Giving people the chance to find out where they fit 
helps Zappos keep employees happy, excited, and engaged. 


For many who’ ve plugged along in a very traditional career, this culture can be a 
breath of fresh air. “All of my career before Zappos I was mostly focused on 
recruiting,” says Foley. It was a rote job, she says, and she was burned out. Coming to 
Zappos reinvigorated her. It was the culture, she says. “It’s what makes me excited 
coming to work.” 


That’s what Zappos wants, what any company should want. It’s what I want. I 
want people to love coming to work. It’s a change in mind-set. From working for a 
company to working withmy company. It’s a mind-set that some people have a 
problem embracing. It’s why Zappos focuses on internal promotions. They’ve found 
that people who come in from the outside, especially at more senior levels, have a 
hard time adjusting. ““We’re a mix of entrepreneurial and innovative,” says Foley. But 
that’s only half of it. “The other half is collaboration.” The company wants people to 
work together in relationships across the organization. This doesn’t fit sometimes with 
standard corporate culture. One senior manager told me, “I don’t really have a title. 
We think as a group we can do much better.” 


Often at companies you'll see managers who want to run their own area without 
transparency, and without collaboration. They create an “us versus them’ dynamic. 
Turf lines are drawn, and you can almost see the different divisions plotting against 
one another like something out of a Machiavellian medieval court. Imagine how much 
more productive a company would be if everyone worked together toward a common 
goal. Imagine a company that everyone thinks of as my company, where every day is a 
chance to get better, to do something better, to learn something new. Instead, most 
corporations set up an environment where people are more involved in politics than in 
making a profit. 


At Zappos if you don’t fit with the team, and the culture, you don’t fit in the 
company. Their annualized attrition rate is 12 percent, and most of the turnover, they 
say, 1s in their call center. That’s because they fire people who aren’t passionate about 
delivering for customers. Zappos sees those people as the public face of the company, 
and its standards are high. Folks at Zappos are flexible on a lot of things, but not on 
that. 


I’ve seen this same dynamic play out on teams. One person on a team might have 
specialized knowledge or skills—knowledge they hoard like misers. They see it as a 
possession that ensures their job. Scrum, through its Retrospectives and transparency, 
illuminates this kind of behavior almost immediately. It becomes obvious where the 
roadblocks are, where the waste is. When I run a company, I tell those people with 
“miser” habits that they don’t have the luxury of holding the team and the company 
hostage. They can either change their mind-set or go work for someone else. 


Zappos has found that, the more senior the new hire, the more ingrained their 


thinking, and, therefore, the harder they have to work to shed old ways of doing things. 
Scrum gives people a framework for doing that. It provides a structure for the whole 
organization to head toward a common goal. Its pillars are transparency, teamwork, 
and collaboration. Many companies now embrace that philosophy, and inevitably 
those that don’t lose out to those that do. 


Zappos went from $1.6 million in sales in 2000, to over a billion in 2008. That’s 
a growth rate of 124 percent each year for eight years in a row. I don’t know about 
you, but I think that’s a pretty convincing argument for making people happy. And 
Scrum is a tool kit you can use to get there. 


Pop the Happy Bubble 


One thing happiness is not—at least the kind/’m talking about—is complacency. 
Rather, it’s the opposite of that: positive and passionate engagement. As Christa Foley 
at Zappos says, happiness is the farthest thing from passivity. “I love coming to work. 
Rather than [encouraging you to become] complacent, our positive and uplifting 
culture makes you work harder.” They do have to screen out people who think that 
working at a happy place means not working. They want people who use joy as a 
driver. 


And they aren’t alone in that. The Harvard Business Review focused its entire 
2012 January—February issue on happiness. What they found was 


... that the only route to employee happiness that also benefits shareholders is 
through a sense of fulfillment resulting from an important job done well. We 
should aspire not just to make employees “happy,” but to do so by helping them 
achieve great things. In short, we should earn our employees’ passionate 


advocacy for the company’s mission and success by helping them earn the 


passionate advocacy of customers.” 


And that passionate advocacy has tangible benefits. Happy employees show up at 
work, they bear down harder, and not only do they not leave a company, they attract 
others like them who share the same drive. In their article for the HBR issue, Gretchen 
Spreitzer and Christine Porath decided not to call these people “happy,” because of 
the connotations of complacency. Instead, they called them “thriving.” They found that 
these people performed 16 percent better than their peers, had 125 percent less 
burnout, were 32 percent more committed, and 46 percent more satisfied with their 
jobs. They took fewer sick days, had fewer doctor’s appointments, and were more 


likely to get promoted.3 
What these “thrivers” share is what ve been writing about throughout this 


chapter—each thriver is vital and passionate, and each is trying to perfect their craft, 
whether they belong to an airplane crew or are a busboy in a restaurant. What can 
companies do to create an atmosphere in which people thrive? Managers can 
encourage autonomy by letting people make their own decisions about their job. And 
they can make sure that employees know everything that’s going on, because, as they 
put it, “Doing your job in an information vacuum is tedious and uninspiring.” 
Managers should also have zero tolerance for incivility and never allow an employee 
to poison corporate culture through abuse or disrespect. And, finally, they should give 
quick and direct feedback. 


Scrum gives people all those things. It’s set up to make them happen, especially 
the direct feedback, which happens every day in the Daily Stand-up meeting, and 
which is what the Sprint Retrospective and the Happiness Metric are designed to 
illuminate. 


There’s one caution I'd like to lay out, though. It’s possible—heck, it happens 
often enough that ve spent significant time studying it—for a “happy bubble” to 
develop. This usually happens after a team has achieved some big success or 
increased their productivity greatly by using Scrum. They’ve self-organized, and they 
feel proud of their progress. And that’s when complacency can set in. They say to 
themselves, Hey, we’ve improved so much, we don’t need to improve any more. They 
hit a productivity plateau and pretty soon thereafter cease to do great work. But they’re 
good enough that, for a time, they live in this happy bubble that insulates them from 
unpleasant truths. They don’t realize that continuous improvement means just that: it 
never, ever stops. When I was a fighter pilot we used to say after three thousand hours 
in the cockpit you need to quit because you become complacent, and that could kill 
you. While a complacent team might be less risky in business, ongoing team 
performance is at risk. 


This complacent attitude often reveals itself with a comment such as _ the 
following: “We deserve to coast; we’ve earned it.” Or individual team members value 
their team spirit and happiness so highly that they don’t want to endanger it. Or they 
fear change itself, feeling that if what they have is working, why alter it? 


Because this is where the forms of Scrum can break down, “happy bubbles” are 
one of my biggest concerns. I’ve seen it again and again: a team might be doing all the 
things Scrum teaches—prioritization, single-tasking, cross-functionality, review 
rituals—but they’ve stopped improving. Often they’re so much better than they were 
before learning Scrum, and they have the successes to prove it, but they rest on their 
laurels. They say, “We don’t need to get any better.” 


It reminds me of the 2004 US Olympic basketball team. There were some top 
players on that team—LeBron James, Tim Duncan, and Allen Iverson, to name just a 


few—and the United States had a history of not only winning but dominating in the 
sport, particularly since professional players had been allowed to participate. The 
American basketball players knew they were the best. Except that they weren’t. They 
lost more games than any US Olympic basketball team had ever lost. They lost to 
Lithuania. Their pride and complacency were their downfall. They were living in the 
happy bubble. 


So how do you pop the bubble before your players embarrass their country on 
live TV in front of billions of people? The first step is being aware of the problem, 
which is why I want teams to measure their velocity every Sprint. I want to know what 
their rate of change is. If there isn’t positive growth, I know we’ve got to bear down. 
And the person I depend on to do this is the Scrum Master. He or she needs to be able 
to see the problem and bring it up with the team. It’s crucial that someone ask the hard 
questions. What you really want is a “Wise Fool.” 


I marvel what kin thou and thy daughters are: they’Il have me whipped for 
speaking true, 
thou’ lt have me whipped for lying; and sometimes I am whipped for holding 


my peace.4 


—King Lear, act 1, scene 4 


The “Wise Fool” is the person who asks uncomfortable questions or raises 
uncomfortable truths. These workers aren’t always easy to have around, since they can 
be seen as troublemakers or not part of the team, but they need to be cultivated and 
used. 


Perhaps the best example is one we’re all familiar with—from the classic Hans 
Christian Andersen story “The Emperor’s New Clothes.” As you'll recall, there was 
once an emperor who adored fine clothes so much, he had a different coat for every 
hour of the day. If you wanted to know where he was, the first place you looked was 
his changing room. One day a few swindlers came to the emperor and swore that they 
had a secret cloth that was so fine that those people who were unfit for office were 
unable to see it. They demanded the finest silk but only pretended to weave it, instead 
“weaving” only air, the fine materials going into their bags. The emperor came to 
check on their progress one day and saw nothing. Remembering that the cloth was only 
visible to those fit for office, he praised it as the finest he’d ever seen. He asked his 
advisers, but they too swore up and down that it was the most wondrous material ever. 
On the day of delivery the swindlers carefully draped the emperor in nothing at all, to 
rave reviews from his court, and so the emperor decided to parade through his city, 
showing people the miraculous cloth. 


You remember how the story ends: No one said anything about the emperor’s 
nakedness, not wanting to be seen as unfit themselves. So the royal procession 
continued down the avenue until a small child called out, “But he isn’t wearing 
anything at all!” At first the child’s father hushed him, but then, beginning with a 
whisper and growing to a shout, the people of the city started shouting, “He hasn’t got 
anything on!” The emperor, while fearing they were right, kept the procession going. 
And his courtiers followed him, holding a train that wasn’t there. 


The Wise Fool is that child—the person who can see that the accepted truth is 
simply a consensual illusion, and that really the emperor has no clothes. So if you have 
a Wise Fool or two, cherish them. 


There are other ways of popping the happy bubble—for example, by bringing in 
new blood and management intervention—but at the root they’re all the same, bringing 
the team face-to-face with a reality they may not want to see. Fortunately, with Scrum 
everything is transparent—how much the team is producing, the quality of their work, 
how happy the customer is. One of Scrum’s virtues is that it makes the uncomfortable 
visible, quickly. By contrast, traditional teams and organizations can blithely walk 
themselves off a cliff and wonder what possibly could have gone wrong. They wait 
too long to get actionable feedback from the market, and from each other. 


Happy Today, Happy Tomorrow 


Psychologists, including Harvard’s Ben-Shahar, say that one way to analyze how 
people approach the world is by asking whether what they’re doing makes them happy 
today, and whether it will make them happier tomorrow. I’ve found it a useful lens to 
look at people in work environments. 


People tend to fall into four types according to Ben-Shahar. The first type, the 
“Hedonist,” is someone who is doing what makes them happy right now. Tomorrow? 
Let tomorrow worry about tomorrow. I'll just enjoy today. I see this kind of behavior 
a lot in start-ups: a bunch of people in the figurative garage just making stuff, because 
it’s cool and it’s fun. But there isn’t a lot of attention paid to creating a sustainable 
product. Very little mental energy is channeled into how this thing will be working in a 
month, let alone a year down the road. 


And what usually happens is that the investors in these guys get worried. So they 
hire a bunch of managers to ride herd on the hackers. And, suddenly, the hackers find 
that the world they enjoyed so much now sucks. There are now all sorts of rules and 
tests and reports. It sucks today, and they think it will suck forever. Call them now the 
“Nihilists.” 


Then there are the guys who were brought in to run the place. They’re the ones 


willing to put in eighty-hour weeks (and willing to whip others to do so), because they 
think they’ Il get promoted later, and they'll be happier. Of course, when they do get 
promoted, they just have a new set of headaches to contend with that require more 
time. They enjoy the rat race. 


The fourth type of person is the one that Scrum tries to identify and encourage— 
the individual who is working at stuff that is fun today but has an eye toward a better 
future and who is convinced it will be fun forever. This sort of person rarely 
experiences burnout or disillusionment. He’s spared the negative feelings toward 
work suffered by the hedonists, the nihilists, and the rat-race-addicted managers who 
strive to make everybody toe the line. 


What Scrum does is promote a single, galvanizing mind-set. By having everyone 
work together, the team helps the hedonist look ahead, convinces the nihilist there is a 
future without whining, and tells those managers stuck in an unending rat race that 
there actually is a better way. 


That’s why I implemented the Happiness Metric in my company. It helps the team 
help its members become better people. It removes the causes of unhappiness 
systematically, carefully, and incrementally. It empowers people to change themselves 
and attaches an incentive to doing so. 


Remember the Fundamental Attribution Error? When you’re surrounded by 
assholes, don’t look for bad people; look for bad systems that reward them for acting 
that way. Then you use the Happiness Metric to fix it. 


In high school or college many of us studied the American psychologist Abraham 
Maslow’s “hierarchy of needs.” It laid out, in pyramid form, the needs that humans 
take care of first and then those that become more pressing as lower ones are satisfied. 
At the pyramid’s base are physiological needs: air, water, food, clothing, and shelter. 
If we don’t have those, we can’t even begin to think about anything else. The next layer 
is safety—not just physical and financial, but also the assurance of good health. It’s 
important to have some access to medical care. Interestingly, many people stop there, 
even though the next layer holds what we absolutely need as humans but that society 
often ignores: love and belonging—that connectedness Zappos talks about. Above that 
is the need for self-esteem and respect from others. And at the pyramid’s very top is 
the need to achieve one’s full potential. 


It’s that top layer that Maslow was most interested in, and that Scrum focuses on: 
helping people achieve personal growth and fulfillment. People high up on that 
pyramid are not only happier and more fulfilled, they’re more effective and 
innovative. And they’re able to deliver greatness. 


I can almost see you nodding now, because we all know that pyramid on a gut 


level, even if some of us have never seen it spelled out. The trick is to move up to 
those lofty heights, and to then have a way of precisely gauging what impact you’re 
having. If you’re running a business, maybe you measure greatness by revenue and 
growth. If you’re trying to make sick people better, maybe you measure greatness by 
the number of those who don’t die. If you’re trying to change the world, maybe you 
measure greatness by how much you’ve changed it. If you’re just trying to get your 
honey-do list done, maybe you measure greatness by how many weekend afternoons 
you have free to go fishing. 


It’s not enough just to be happy. Happiness needs to be harnessed to produce 
results. All the elements of Scrum come together to help a person do just that. The real 
trick? Priorities. We will talk about those next. 


THE TAKEAWAY 


It’s the Journey, Not the Destination. True happiness is found in the 
process, not the result. Often we only reward results, but what we really 
want to reward is people striving toward greatness. 


Happy Is the New Black. It helps you make smarter decisions. Plus, when 
you're happy, you’re more creative, less likely to leave your job, and more 
likely to accomplish far more than you ever anticipated. 


Quantify Happiness. It’s not enough just to feel good; you need to measure 
that feeling and compare it to actual performance. Other metrics look 
backward. Happiness is a future-looking metric. 


Get Better Every Day—and Measure It. At the end of each Sprint, the 
team should pick one small improvement, or kaizen, that will make them 
happier. And that should become the most important thing they’I] accomplish 
in the next Sprint. 


Secrecy Is Poison. Nothing should be secret. Everyone should know 
everything, and that includes salaries and financials. Obfuscation only 
serves people who serve themselves. 


Make Work Visible. Have a board that shows all the work that needs to be 
done, what is being worked on, and what is actually done. Everyone should 
see it, and everyone should update it every day. 


Happiness Is Autonomy, Mastery, and Purpose. Everyone wants to 
control their own destiny, get better at what they do, and serve a purpose 
greater than themselves. 


Pop the Happy Bubble. Don’t get so happy that you start believing your 
own bullshit. Make sure happiness is measured against performance, and if 
there is a disconnect, be prepared to act. Complacency is the enemy of 
success. 


CHAPTER EIGHT 


Priorities 


I first met Scott Maxwell at Johnny’s Luncheonette in Newton Center a few years ago. 
I’ve told you about him before. He’s the founder of OpenView Venture Partners, and 
he’s the one who figured out that working longer hours creates more work than it 
accomplishes. ve been working with OpenView and its portfolio companies for 
almost eight years now, and in every single one we’ve seen dramatic increases in 
productivity. But Scrum isn’t just about making teams go faster. It’s about boosting 
impact, which, in the case of the VC guys, takes a simple form: revenue. If a company 
isn’t making money, you don’t have a successful venture; you have a hobby. 


I can’t tell you how many companies I’ve seen with great ideas and a really cool 
product—something that gets everyone excited, that seems to fill a market niche, that 
just seems as if it should be successful. It’s just so cool. But despite megadoses of 
imagination, inspiration, and hard work, the people making the product can never 
figure out how to actually make money with it. 


What’s the difference between a Pets.com and a Zappos? They both saw a market 
segment that people spend billions of dollars a year on. They both saw a way to 
deliver products more easily and cheaply online. One became emblematic of dot-com 
excess and the squandering of millions and millions of dollars; the other company is 
worth more than a billion dollars. They both had vision—what Pets.com didn’t have 
was a Sense of priorities. They didn’t know what to do when. 


I like to show people this Venn diagram. 


THE PRODUCT OWNER MUST BALANCE 
MULTIPLE PRODUCT ATTRIBUTES 


es _ PRODUCT 
VISION 


Every company needs to think about this diagram. If you concentrate only on what 
you can build, you can end up making something that nobody actually wants, even if 
you’re passionate about it. If you concentrate only on what you can sell, you can 
promise things you can’t build. If you only build what you can sell but aren’t 
passionate about, you end up working hard to build mediocrity. But in the center, that 
sweet spot, is a vision rooted in reality—a vision with a real possibility of becoming 
something great. In this chapter I’m going to show you how to get there. The preceding 
chapters have focused on how to do things faster and better. This chapter is how to 
make “faster and better” work for you—how to achieve greatness. 


Scott Maxwell says that the true power of Scrum lies in its ready, prioritized, and 
sized Backlog of what to do. This is why he implemented it at the venture group, and 
why he thinks it is a critical competitive advantage. 


The Backlog: What to Do When 


The first thing you need to do when you’re implementing Scrum is to create a Backlog. 
It can be hundreds of items long, or contain only the few things that you need to figure 
out first. Of course, you need a clear idea of what you want at the end of the work. It 
could be a product, a wedding, a service, a new vaccine, or a house painted. It could 
be anything, but once you have a vision, you need to consider what it will take to make 
that happen. 


There’s a company I’ve been working with recently that builds automation 
systems for buildings—heating, cooling, electric, plumbing, the whole kit and 
caboodle. One of their new products is a home automation system. They’re building a 
system that can control every aspect of your home, from opening the front door, to 
controlling your heating costs, to turning on your lights—all from your mobile device. 
So they sat down and wrote out a list of everything they would need to make that 
happen—switches, controllers, interfaces, sensors, communication protocols, 
whatever. Not the specific rules and pieces, actually, but all the “stories” they would 
need. 


So they wrote things such as, “As a home owner, I want to be able to see who is 
at my door, so that I can open the door only for those people I want to come in.” They 
wrote stories about opening the garage door, turning on the HVAC, controlling the 
lights. They kept writing until they had a list of all the things they thought their system 
would need to do to be a compelling purchase. 


The list turned out to be hundreds of items long. It’s a big, complicated system. 
The idea behind the Backlog is that it should have everything that could possibly be 
included in the product. You’re never going to actually build it all, but you want a list 
of everything that could be included in that product vision. 


The key, though, is what you decide to do first. The questions you need to ask 
are: what are the items that have the biggest business impact, that are most important to 
the customer, that can make the most money, and are the easiest to do? You have to 
realize that there are a whole bunch of things on that list that you will never get to, but 
you want to get to the things that deliver the most value with the lowest risk first. With 
Scrum’s incremental development and delivery, you want to begin with the things that 
will immediately create revenue, effectively “de-risking” the project. And you want to 
do that on the features level. You want to start delivering value to your customers as 
soon as you possibly can. You want something that is completely Done—that you can 
show. It could be just a small part of the larger project, but it should be demonstrably 
Done. If you’re painting a house, maybe what’s Done first is all the trim in the living 
room. 


In product development there’s a hard-and-fast rule that has been proven over 
and over again. I talked about this earlier: 80 percent of the value is in 20 percent of 
the features. Think about that for a moment. In anything that you buy, most of the value 
—most of what people want—is in only a fifth of what has been built. In this 
company’s case they looked at this huge list of things that could be included in their 
home automation system, and they knew—they knew—that customers really only 
wanted 20 percent of them. The trick of Scrum is figuring out how you build that 20 
percent first. In traditional product development, teams don’t know what that 20 
percent is until they deliver the whole thing. That means that fully 80 percent of their 
effort is waste. And you know how I feel about waste. 


What if you could start delivering things five times faster than your competition, 
with five times the value? That’s a winning hand. 


So this automation company sat down with a huge list of features and asked 
themselves: “Okay, what do we do tomorrow? What’s most important to the customer? 
How do we deliver value to them faster than anyone else?” As Scott Maxwell says, 
the difficult part isn’t figuring out what you want to accomplish; it’s figuring out what 
youcan accomplish. This is true whether you’re building a house or car, writing a 
book or videogame, or cleaning up crime or trash. Figure out where the most value can 
be delivered for the least effort, and do that one right away. Then identify the next 
increment of value, and the next. Faster than you think, you'll have created something 
or delivered something with demonstrable, real results. The key is prioritizing the 
work. 


How do you do that? Well, first you need someone who can figure out both what 
the vision is, and where the value lies. In Scrum we call that person the Product 
Owner. 


The Product Owner 


There are only three roles in Scrum. Either you’re part of the team, and you’re doing 
the work, or you’re a Scrum Master, helping the team figure out how to do the work 
better, or you’re a Product Owner. This is all laid out in the appendix. The Product 
Owner decides what the work should be. He or she owns the Backlog, what’s on it, 
and, most important, what order it’s in. 


When I started the first Scrum team in 1993, I didn’t have a Product Owner. I was 
part of the leadership team and had a bunch of other responsibilities besides figuring 
out exactly what the team should do in each Sprint. I carried out management and 
marketing duties, dealt with customers, and plotted strategy. But in that first Sprint I 
figured I could handle the Backlog. I just needed to make sure I had enough “stories” 
and features for the team to work on during the next Sprint. The problem was, after the 
second Sprint we introduced the Daily Stand-up meeting. Velocity went up 400 
percent in the next Sprint, and the team finished in a week what we thought would take 
us a month. There was no more Backlog for them to work on! I thought ’'d have a 
month to create more “stories.” A great problem to have, admittedly, but one that had 
to be addressed. So I thought about this role of Product Owner and what qualities 
someone would need to execute it properly. 


My inspiration for the role came from Toyota’s Chief Engineer. A Chief Engineer 
at Toyota is responsible for a whole product line, such as the Corolla or the Camry. 
To do this, they have to draw on the talents of groups specializing in body engineering, 
or chassis, or electrical, or whatever. The Chief Engineer has to draw from all those 
groups to create a cross-functional team capable of creating a car. Outside of Toyota 
everyone thinks of these legendary Chief Engineers (or Shusas, as they were originally 
called) as all-powerful leaders of the “Toyota Way.” And in a way they are. But what 
they don’t have is authority. No one reports to them—trather, they report to their own 
groups. People can tell Chief Engineers that they’re wrong, so they have to make sure 
they’re right. They don’t give anyone performance appraisals or promotions or raises. 
But they do decide on the vision of the car, and how the car will be made—by 
persuasion, not coercion. 


It’s this idea that I wanted to embody within Scrum. John Shook of the Lean 
Enterprise Institute once began his description of the Chief Engineer role by quoting 
the US Marine Corps leadership manual: 


An individual’s responsibility for leadership is not dependent on authority.... the 
deep-rooted assumption that authority should equal responsibility is the root of 
much organizational evil. I believe misunderstanding around this issue 1s 


rampant, problematic, and runs so deep in our consciousness that we don’t even 
realize it 


Reflecting on my time at West Point and in Vietnam, I found myself agreeing that 
leadership has nothing to do with authority. Rather, it has to do with—among other 
things—knowledge and being a servant-leader. The Chief Engineer can’t simply say 
something has to be done a particular way. He has to persuade, cajole, and 
demonstrate that his way is the right way, the best way. It usually takes someone with 
thirty years of experience to fill the role. I wanted that in Scrum, but I’m also well 
aware that very few people have that level of skill and experience. So I split the role 
in two, giving the Scrum Master the how and the Product Owner the what. 


Even in those early days of Scrum I knew that I needed someone who was deeply 
connected to the customer. The Product Owner needed to be able to deliver feedback 
to the team from the customer each and every Sprint. They needed to spend half their 
time talking to the people buying the product (getting their thoughts on the latest 
incremental release and how it delivered value) and half their time with the team 
creating the Backlog (showing them what the customers valued and what they didn’t). 


Remember, the “customer” could be the general consumer, a big bank, your 
husband, or someone who needs the rotavirus vaccine and is depending on you to get it 
to them. The customer is anyone who will get value from what you’re doing. 


But I didn’t want a manager. I wanted someone the team would believe and trust 
when he prioritized the Backlog. So I went and got the smartest guy in Product 
Marketing—not in Engineering, mind you, but Marketing. And that’s how Don Rodner 
became the first Product Owner. He knew the product we were making not from a 
technical point of view—although he understood enough of that to communicate with 
the engineers—but, rather, from a customer point of view. What did the people who 
were actually using the product need? When you’re picking a Product Owner, get 
someone who can put themselves in the mind of whoever is getting value from what 
you're doing. As a friend of mine says, “My wife is the perfect Product Owner; she 
knows exactly what she wants. I just implement it.” 


Not only does the Product Owner need a wider range of skills than a Scrum 
Master, they need to be held to a different set of standards. The Scrum Master and the 
team are responsible for how fast they’re going and how much faster they can get. The 
Product Owner is accountable for translating the team’s productivity into value. 


Over the years I’ve boiled down the essential characteristics of a Product Owner 
to four: 


One, the Product Owner needs to be knowledgeable about the domain. By this I 
mean two things: the Product Owner should understand the process the team is 


executing well enough to know what can be done and, just as important, what can’t. 
But the Product Owner also has to understand the what well enough to know how to 
translate what can be done into true, meaningful value. It could be a computer system 
that helps the FBI catch terrorists, or a teaching method that improves student 
performance in public schools. The Product Owner needs to know the market well 
enough to know what will make a difference. 


Two, the Product Owner has to be empowered to make decisions. Just as 
management shouldn’t interfere with the team, the Product Owner should be given the 
leeway to make decisions about what the product vision will be, and what needs to be 
done to get there. This is important, because the Product Owner is under pressure from 
a lot of different stakeholders, both internal and external, and has to be able to hold 
firm. The Product Owner should be responsible for outcomes, but let the team make 
their own decisions. 


Three, the Product Owner has to be available to the team, to explain what needs 
to be done and why. While the Product Owner is ultimately accountable for the 
Backlog, there needs to be a constant dialogue with the team. Often the team’s 
expertise will inform the decisions the Product Owner needs to make. The Product 
Owner has to be reliable, consistent, and available. Without access to him, the team 
won’t know what to do, or what order to do it in. They rely on the Product Owner for 
“the vision” and, also, market intelligence on what is important. If the Product Owner 
isn’t available to the team, the whole process can fall apart. This is one of the reasons 
I rarely recommend that CEOs or other senior executives be Product Owners. They 
just don’t have the time the team needs. 


Four, the Product Owner needs to be accountable for value. In a business context 
what matters is revenue. I measure a Product Owner by how much revenue they 
deliver per “point” of effort. If the team is producing forty points of work every week, 
I want to measure how much revenue is created for each and every point. But the 
measurement of value could be how many successes a team has. I know one law 
enforcement team that measured value by the number of arrests of wanted felons they 
made each week. I know churches that use Scrum and measure their success by how 
well they’re serving their congregation, and whether it’s growing. The key is to decide 
what the measure of value is and hold the Product Owner accountable for delivering 
more of it. In Scrum this kind of metric is easy to observe because of the method’s 
incredible transparency. 


Now, that’s a lot to ask of one person, and it’s the reason why in big projects 
there’s usually a team of Product Owners to address all the needs. I'll get into the 
details of that later. But first, as a way of visualizing what the Product Owner needs to 
do, I want you to imagine you’re in the cockpit of an F-86 Sabre with the “Mad 


Major,” John Boyd, about to enter a dogfight over the Korean Peninsula. 
Observe, Orient, Decide, Act 


Air-to-air combat during the Korean War took place mainly between American F-86 
Sabres and Russian-made MiG-15s. The MiG was faster, more maneuverable, had a 
greater thrust-to-weight ratio, and was all around a superior aircraft. On paper, MiG- 
15s should have wiped the skies of American pilots. Instead, they were shot down by 
a 10:1 ratio. The struggle to figure out how that could possibly happen shaped the 
future of warfare; it also became critical in the development of Scrum. 


John Boyd was simply the greatest fighter pilot who ever lived, although he never 
shot down an enemy in combat. He flew only twenty-two missions over Korea before 
the armistice, and back then you had to have thirty missions as a wingman before you 
could take the lead as a “shooter.” It was after the war, teaching at the USAF Weapons 
School at Nellis Air Force Base in southern Nevada, that he made his mark. In a 
military that values frequent rotations of personnel, he spent an unprecedented six 
years there as an instructor. 


Fighter pilots are not a humble lot. By the time they show up at Nellis, they’re 
already considered the best pilots in the USAF, and they exhibit a certain swagger. 
Boyd had a foolproof way of dismantling a pilot’s ego so he would actually learn 
what Boyd had to teach. He’d invite them up into the air and have the student fly on his 
“six,” directly behind him—the best position in an aerial dogfight. Then he’d tell the 
student to engage. Without fail, within forty seconds he’d be lining up a kill shot on the 
student’s six, all the while screaming “Guns! Guns! Guns!” into the radio. This was 
before the advent of lasers and computers and simulated weapons. It was that yell that 
told the student he was dead. Boyd’s unfailing success earned him a second nickname 
that would stay with him, “Forty Second” Boyd. 


His other sobriquet, the “Mad Major,” was a moniker earned from his, ah, 
energetic declarations. They were almost always delivered with his face three inches 
from whoever was contradicting him while he poked the opponent’s chest with two 
fingers. Unfailingly, in those two fingers was a lit Dutch Masters cigar. Legend had it 
that, occasionally—quite by accident, I’m sure—he’d light his adversary’s tie on fire. 
At such times, he’d show no contrition, using any weapon in his arsenal to win an 


argument. 
Boyd had the ability to see the whole battle space. As he put it in an oral history: 


I would see myself in a vast ball—I would be inside the ball—and I could 
visualize all the actions taking place around the ball [while] all the time of 


course I am maneuvering.... I could visualize from two reference points. When I 
was fighting air-to-air, J could see myself as a detached observer looking at 


myself, plus all the others around me.2 


This kind of awareness, the ability to see a whole sphere of sky and watch events 
unfold, shaped his military theories and eventually rewrote how America wages war. 


When Boyd left Weapons School, he decided to study engineering, and while 
doing so he created a model of aircraft performance that described air-to-air combat 
in terms of energy relationships. Energy Maneuverability (EM) theory takes into 
account an airplane’s kinetic and potential energies in any situation—its altitude, 
airspeed, and direction—and how fast it can change any of those variables. The theory 
was eventually baked into the way most fighter aircraft are modeled, directly leading 
to the development of the F-15 and the F-16, the dominant fighters of the last forty 
years. 


The problem was, according to Boyd’s theory, the MiG-15 should have wiped 
the floor with the F-86 Sabre. It just didn’t make sense. Boyd, according to Robert 
Coram’s biography, went into frequent trances for days as he tried to figure it out. He 
was sure his theory was right, but what was the reason for the 10:1 kill ratio racked up 
by American pilots? Training? That could only explain part of it. Tactics? Maybe, but 
again that factor wouldn’t lead to so lopsided a result. And then it hit him. The 
American pilots could see better and act faster. Not through any quality inherent in the 
pilots, but through some simple design choices. The Sabre had a bubble canopy, while 
the MiG had one with multiple glass panes and struts blocking the pilot’s vision. The 
F-86 also had fully hydraulically powered flight controls, while the MiG had only 
hydraulically assisted controls. MiG-15 pilots were known to lift weights to give 
themselves the upper body strength to maneuver the aircraft. 


As a result the American pilots could see the MiGs first, and then, crucially, they 
could act on that information faster than the Chinese and North Korean pilots. The 
battle was decided not by what the machine could do, but by how fast observation was 
translated into action. The MiG would take one action, the American pilot would 
respond, and while the MiG pilot was trying to respond to that, the American pilot 
could take another action. He’d respond to each new alignment of the MiG so much 
faster that the more technologically advanced plane became a sitting duck. 


The same phenomenon occurred in Vietnam when I was there. By then, there 
were different airplanes squaring off, the MiG-21 and the F-4, but, once again, the 
superior visibility of the F-4 overcame the superior maneuverability of the Soviet- 
made plane. As Boyd would put it, his most famous innovation put pilots “inside the 
enemy’s decision loop.” 


This insight has become fundamental to how wars are fought. And it’s exactly 
what I designed Scrum for—to allow a Product Owner to make decisions quickly, 
based on real-time feedback. By getting constant input from whoever is getting value 
from what you’re doing—be it the person clicking the Buy button on Amazon, the 
parishioners of your church, the children in a classroom, or someone trying on a dress 
—you’re in a position to constantly adjust your strategy and more quickly succeed. 


The idea goes by the somewhat ludicrous name of the OODA loop. That’s short 
for Observe, Orient, Decide, and Act. And while it may sound funny on the tongue, 
it’s deadly in war and in business. Getting inside someone’s loop reduces them to 
confusion and doubt. They overreact and underreact. As Boyd put it in a briefing he 
gave to other officers, “He who can handle the quickest rate of change survives.’ See 
the OODA loop chart on this page. 


“Observe” is fairly obvious—it’s clearly seeing the situation as it unfolds. This 
isn’t as simple as it sounds, though. Boyd described it as moving outside of yourself 
so as to see the whole picture—not merely your own point of view. 


“Orient” is not just about where you are; it’s also about what outcomes you’re 
capable of seeing—the menu of alternatives you create for yourself. Factoring into that 
creation, according to Boyd, are genetic heritage, cultural traditions, previous 
experiences, and, of course, the unfolding circumstances. Thus, Orientation reflects not 
only how you see the world and your place in it, but what world you’re capable of 
seeing. 


The combination of Observation and Orientation leads to a “Decision,” which 
leads to “Action.” Then the loop begins again with Observation of the results of your 
actions and those of your opponent—or, in the business world, Observation of the 
reaction of the marketplace. 


What Scrum does, by delivering a working increment, is give the Product Owner 
the ability to see how much value that increment creates, how people react to it. Then, 
based on that information, she can change what the team will do in the next Sprint. 
This sets up a constant feedback cycle that accelerates innovation and adaptation, and 
enables the Product Owner to measure how much value is delivered. (In business we 
measure that by money. If I’m painting the interior of a house, I might measure it by 
rooms completed.) The Product Owner thus has the ability to adjust on the fly to a 
constantly changing world. 
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It can be difficult to imagine incremental releases on products or projects that 
don’t seem, on the face of it, to have any value until they're complete. For example, 
how do you do incremental releases of a car? Or a hundred-million-dollar video 
game? The key is to look for what slices actually hold value—enough value that you 
can get real feedback on them and react in real time. 


Let’s take cars, for example. Toyota developed the Prius from concept to 
delivery in fifteen months, faster than any delivery they’d ever done. While the team 
that designed and built the Prius didn’t start selling their car before it was completed, 
they did start rapidly prototyping the car so that the Chief Engineer could “kick the 
tires” and see if the team was going in the right direction. This kind of rapid 
prototyping—making fully functional vehicles before release and then improving those 
prototypes over and over until you have the product you want to sell to consumers— 
can drive incredibly fast changes. The key is not to have a fully established design at 
the beginning but, rather, to make a functional prototype, then see what you can 
improve. And then, having improved it, to make the next prototype and improve that 
one. The idea is that the sooner you have some real feedback, the faster you can make 
a better car. 


Team WIKISPEED, which I wrote about in chapter four, produces full prototypes 
of their car every week. And they sell those prototypes. These transactions don’t occur 
in a mass market—Team WIKISPEED isn’t ready for that yet—but there are early 
adopters who are willing to put down $25,000 for those early prototypes. When 
you’re thinking about building something, don’t assume you can’t deliver something of 
value until the very end. Instead, try to think about the minimum viable product. What 
is the absolute least I can build and still deliver some value to a customer? 


Videogames are another good example. Nowadays more and more developers 
are letting early adopters pay for early “alpha” access. That way the developers get 
feedback from their most dedicated fans before the game really works. This allows 
them to see how people actually react, rather than guess how they will react. 


Depending on the industry you’re a part of, or the organization you run, it can be 
difficult to wrap your head around this idea of incremental releases. A fallback, if you 
can’t put something before an external customer, is to identify an internal customer— 
for example, the Product Owner—who can act in lieu of the public. Show your 
internal customer whatever will elicit useful feedback: bits and pieces of a real-estate 
expansion plan, a factory-upgrade design, a braking-system rebuild, a volunteer 
service campaign—whatever. The idea is to create for yourself an opportunity to 
inspect and adapt. A company or organization that can’t react to changing conditions, 
competitors, or tastes is in trouble. 


Boyd puts it this way: 


We want to get inside another guy’s tempo or rhythm, where we will pull him 
down.... We gotta get an image or picture in our head, which we call orientation. 
Then we have to make a decision as to what we’re going to do, and then 
implement the decision.... Then we look at the [resulting] action, plus our 
observation, and we drag in new data, new orientation, new decision, new 
action, ad infinitum.... Orientation isn’t just a state you’re in; it’s a process. 
You’re always orienting. ... 

A nice tight little world where there’s no change ... [creatures who live in 
such a world are] dinosaurs; they’re going to die. The name of the game is not to 
become a dinosaur. If you’re in an equilibrium condition, you’re dead.... The 
underlying message is simple: there is no way out.... That’s the way it is, guys.4 


That’s the way it is, guys. As I said in chapter one, there’s a pretty stark choice in 
front of you: change or die. If you don’t get inside your competition’s decision loop, 
they’ Il get inside yours. As Boyd said, “What I want to do is fold my adversary back 
inside himself.... Then I can drive him into confusion and disorder and bring about 
paralysis.” I don’t know about you, but me, I’d rather be on the doing end of that than 
the receiving end. 


First Things First 


So you have a Product Owner who’s constantly updating the Backlog, ordering the 
stuff to be built and delivered. When you have a few hundred items, that ordering 
process can get pretty complex pretty fast. The key is to figure out how to deliver the 
most value the most quickly. There may be many millions of ways to arrange that 
Backlog, but the one you want delivers those 20 percent of features that hold 80 
percent of the value as quickly as possible. Your first guess for the first Sprint almost 
certainly won’t be the right one, but it will be your best guess at the time. 


But that’s just your first guess. After the first Sprint, once you’ve completed the 
OODA loop and delivered some product to customers, you'll change that order, 
realizing that another arrangement is actually better. 


And then you keep doing it, continually updating and re-prioritizing the Backlog 
each Sprint, tacking toward the order that delivers value the fastest. You'll probably 
never reach the absolute perfect order, but you want to move toward it step by step, 
Sprint by Sprint. 


The key thing to remember is that the order is always in flux. The right order one 
week won’t be the same the next. Your environment will have changed. You'll have 
learned new things. You’ll have discovered that some things are easier and some 
harder. So this constant shifting of the Backlog order happens every single Sprint. The 
key is to acknowledge uncertainty, to fully accept that your current snapshot of order 


and value is only relevant at that one particular moment. It’ll change again. And again. 
And again. 


One bad habit a company can fall into, because of constantly shifting market 
needs and because managers don’t know exactly where the most value lies, is 
prioritizing everything. Everything is top priority. The adage to keep in mind comes 
from Frederick II of Prussia, later to be called “the Great’: “He who will defend 
everything defends nothing.” By not concentrating both your resources and your mental 
energies, you thin them out to irrelevancy. 


A few years ago I celebrated my seventieth birthday in Normandy in France. I 
went to see the famous beach where my own father had landed during the D-day 
invasion. At low tide, Omaha Beach looks as if it slopes for miles before sinking into 
the distant sea—a seemingly endless spread of sand. Running up that long, wet slope 
into the face of the German guns must have required a courage that can only be 
imagined. Walking through the graves of the thousands who died that day demands 
silence and respect. But as I started reading about the German defenses, I realized that 
one of the reasons the American landing was successful was that the Germans forgot 
Frederick the Great’s admonition. So confused were they by Allied deceptions that 
they spread their forces across the entire coast of France. As a result, the Allies could 
isolate each German unit separately, defeating each and then moving on to the next. 
The Nazis didn’t prioritize properly, and, thankfully, they lost it all. 


Release 


So you have the priorities. You know where 80 percent of the value lies. When do you 
deliver your product? Here is where Scrum can deliver value radically faster. 
Whenever you’re making something, you want to put it in the hands of those who are 
actually going to use it as fast as possible. You want to do this even before you make 
20 percent of the features. You want to do this with something that delivers at least a 
tiny bit of value. I call this a “Minimum Viable Product,” or MVP. This should be the 
thing you show to the public for the first time. How effective does it have to be? Well, 
it should actually work, though to a person who has been working on it, it may seem 
kind of embarrassing. You need to get that product out to the public as early as is 
feasible! This will get you the feedback you need to power your decision loop and 
prioritization. This is Version 0.5. This is a camera that can take a picture but can’t 
focus. This is a dining room set with two chairs. This 1s distributing a vaccine to five 
out of the hundred villages you’ re trying to help. It’s almost laughably incomplete. 


But what it gets you is feedback. The camera’s body is really awkward to hold 
because the shutter button is in a weird place. The chair’s wood doesn’t match the 
table’s closely enough. You manage to offend the village elders through a totally 


avoidable social faux pas. Make those mistakes early, with as little damage as 
possible. 


Then, when you do an official release, or a rollout of a big program, you'll have 
already adjusted and found out what people actually value. In our camera example, 
maybe it turns out that picture takers said that having a landscape mode and being able 
to share photos on Facebook were equally valuable, but when they actually started 
using it, they never used the landscape mode but always wanted to post photos on 
Facebook. 


This allows you to make the features they value, first, and release your product 
when you’ve only done about 20 percent of the work. You know it’s not perfect, but 
it’s darn close. Every hour spent polishing the apple is lost opportunity for value. 
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What’s great about this process is that it’s iterative: just “rinse and repeat.” Once 
people have your product or service or change in their lives, they’ Il tell you what the 
next most valuable things are. Then develop 20 percent of that, and deliver again. And 
again. 


With this incremental-release process, in the time it would’ve taken you to create 
half of the features of your initial product or project, you’ ve now released 200 percent 
of the value, in half the time. That’s the real power of Scrum. That’s how it can 
fundamentally change not only how you work, but how you live your life. Don’t focus 
on delivering a whole list of things—everything and the kitchen sink—focus on 
delivering what’s valuable, what people actually want or need. 


I’m reminded of stories out of Iraq or Afghanistan. They went like this: An 
American platoon comes into town, looks around, and says, “These people are raising 
chickens. Let’s build them a chicken-processing plant.” So they spend millions of 
dollars building a state-of-the-art chicken plant. They don’t consider that there’s 
almost no regular electricity, or that the townsfolk are mostly illiterate and can’t easily 
be trained on the equipment. Then someone comes to town and asks the villagers, 
“What would really help you?” and they say, “You know, a footbridge across the river 
would be great, so we don’t have to spend half a day going to the nearest crossing to 
get to market.” That footbridge costs a few hundred dollars. It looks a lot less 
impressive than a big plant. It doesn’t sound dramatic when you talk to your bosses 
back in Washington. But to those townspeople, it’s infinitely more valuable than the 
fancy building with the now-rusting machines. 
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Another point worth making is that sometimes you finish early. Let’s say you’re 
making a super, next-generation alarm clock for Alarm Clock Inc. You have a list with 
dozens of features on it: a clock, a snooze button, a timer, a loud alarm, a radio, an 


iPhone dock, a GPS—whatever. But being a savvy Product Owner, you prioritize 
what people really want: an easy-to-set-up alarm, sufficient loudness, a radio, and a 
display vivid enough to be seen whether the room is bright or dark. And when your 
team is done with that, you realize that they’ ve actually created the most elegant alarm 
clock ever made. It’s the Apple iPod of alarm clocks. It’s beautiful and does one thing 
really, really well. Instead of having your team build on to it additional features, you 
release that clock and start work on the next project. The team can deliver more value 
doing something else. 


Money for Nothing and Change for Free 


At this book’s beginning, I told you the story of the Sentinel project at the FBI. If you 
remember, an outsourced contractor spent hundreds of millions of dollars building 
software that didn’t work. One of the big sources of the cost overruns there—and in 
just about any contract, be it to build computer software, airplanes, or buildings—is 
change fees. Racking up change fees is actually the business model of a bunch of 
government contractors. They’ll underbid a project, knowing that they’I] make a profit 
because of change orders. When a contract is written on a years-long project with all 
the requirements spelled out in those pretty-looking charts, it’s tempting to say, ““Well, 
that covers it.” Then the contractor says, “I’m agreeing to do this and only this. /f you 
want any changes, it will cost you.” This after-the-fact billing has become the center 
of so much cost that companies and agencies have set up Change Control Boards. 
From a cost point of view, it makes sense. Limit the number of changes, and you'll 
limit the cost associated with them. 


What the bean counters don’t realize is that they’re setting up a system that is 
designed to deny people what they actually want. They’re trying to limit cost, but in 
doing so, they’re limiting learning, innovation, and creativity. If you begin a project 
and realize a little way in that the real value, that 20 percent, doesn’t reside in the 
features you laid out—it lives in a different set of things you discovered in the process 
of doing the work—traditional project management is set up to stop you. It’s set up to 
stop delivering value faster. 


Plus, the effort to “exercise firm control” doesn’t even work! Even with Change 
Control Boards trying to limit changes, the need for change is so great that they’re 
often overruled. Without the changes there wouldn’t be any value in the project. So, 
grudgingly, the Change Control Boards allow it, and the project costs more. And then 
there’s another change that has to be done. And, whoops, there’s another. And pretty 
soon the project is millions of dollars over budget, and a year, or two, or five years 
late. 


That’s why I came up with the idea of “Change for Free.” In a standard fixed- 


price contract, just say changes are free. List all the functionality you expect; for 
example, if you’re building a tank, you want one that can go seventy-five miles per 
hour and shoot ten rounds a minute, has seating for four, has AC, etc., etc-—everything 
you think you need for that tank. The builder looks at that description and says, Hmm, 
making that engine, I’1l call that 100 points, the loading mechanism, let’s call that 50, 
the seating, 5, etc., on down the list. At the end there is a set number of points for each 
feature. Then every Sprint, the customer, who in this scenario is contractually 
obligated to work closely with the Product Owner, can change priorities completely. 
Any item or feature in the Backlog can be moved anywhere else. And new features? 
No problem: just drop equivalently sized features from the deliverables. Oh, you want 
a laser-guided system now? Well, that’s 50 points of work—to compensate for that 
addition, let’s drop 50 points of low-priority features from the bottom of the Backlog. 


A few companies have taken to a new level this idea of only delivering to a 
customer high-value features. A few years ago I heard about a Scrum developer that 
got a $10 million contract to deliver software for a big construction company. The two 
parties agreed on a twenty-month time frame. But the Scrum company inserted a clause 
into the contract. If the construction firm wanted to terminate at any time, they could— 
they’d just have to pay 20 percent of the value of the remaining contract. Basically, if 
the software worked the way the construction firm wanted, they could stop the Scrum 
shop from building any more. 


The software developer started Sprinting. They did one-month Sprints. After the 
first month, the customer redirected some of the developer’s effort to get more value. 
In the second month, the same thing. After the third month, the customer terminated the 
contract, took the software, and put it to work. They had the value they needed. 


Let’s do a little math here to see how everyone won. In the first three months of 
the contract the customer paid out $1.5 million to the Scrum firm. Terminating the 
contract early required them to pay 20 percent of the remaining $8.5 million—that’s 
$1.7 million. They paid out $3.2 million for a piece of software they thought would 
cost $10 million, and they got it seventeen months early. 


And they weren’t the only winner. The Scrum company bid on the contract with 
an expected profit margin of 15 percent. So they spent $1.3 million on development in 
those first three months. But they received $3.2 million. Their profit margin went from 
15 percent to 60 percent. That’s a 400-percent increase in earnings. And now, with 
their developers idle, they could bid on other projects. That’s not just good business. 
That’s an early-retirement strategy. 


They could do this because of the building blocks of Scrum. By managing 
themselves as a cross-functional unit, the team was able to accelerate quickly, 
delivering more value faster. At the end of every Sprint an increment of the product 


was Done. It worked. It could be deployed immediately. Each Sprint the Product 
Owner was able to re-prioritize the Backlog based on customer feedback. And when 
there was enough value created for the customer, everyone stopped working. In this 
way Scrum aligns everyone’s interests: those of the team, the Scrum Master, the 
Product Owner, the customer, and the company. Everyone works toward the same goal 
and with the same vision: deliver real value as fast as possible. ma big believer in 
win-win situations, and making more money delivering better products at a lower 
price strikes me as a pretty good deal. 


Risk 


Management of risk is at the heart of any successful venture. What Scrum allows you 
to do is reduce the risks of failure. The three most common types are market risk, 
technical risk, and financial risk. Or, to put it another way: Do people want what 
we’re building? Can we actually build it? Can we really sell what we’ve built? 


Ive written a lot about market risk. Scrum helps you minimize it by emphasizing 
incremental delivery. It allows you to put a product in front of customers faster. And 
by obtaining feedback early and often, you can make small changes on the spot rather 
than be forced into big changes after you’ve invested millions of dollars and realize 
that what you’re building isn’t really what the customer actually wants. It’s often what 
the customer said they wanted at the beginning of the process, but in reality people 
don’t know what they really want until they can try something out. A lot of business 
advice revolves around failing quickly. I prefer to think about delivering fast. 


Technical risk is interesting. The question of whether it’s actually possible to 
build what the customer wants 1s a tricky one, especially if youre making something 
that 1s physical, which requires plants and tooling and up-front investment. 


Remember the company with the home automation system? Well, they 
approached it by doing what is called “set-based concurrent engineering.” What that 
means in English is “building a few different prototypes to see which one works best 
before going into full production.” For example, they knew that they needed a camera 
so customers could see who was knocking at their door and buzz the visitor in. The 
most expensive part of the camera, and the one that required the most lead time, was 
the lens. Should it be plastic? Glass? Crystal? What holds up in any weather? What 
scratches easily? What gives the clearest picture? How much does each type cost to 
manufacture? 


Instead of making the decision up front and going full bore into manufacturing, 
they built three different fully functional lenses and compared them. Since they were 
only really trying to figure out the lens question, and they had to do it first because of 
long lead times in manufacturing, they tested each lens using a laptop-camera setup. 


Turned out, glass met the criteria the best. But, critically, they were able to make that 
judgment after seeing something that actually worked. The call wasn’t based on 
theoretical constructs. They had something they could look at and touch. With that 
question answered, they could move on to designing the case that would hold the lens 
and the processors that would handle the image. By prioritizing that lens decision, the 
company potentially saved themselves millions. Apple famously does this with all 
their products, often building a dozen fully functioning prototypes before organizing a 
shoot-out to see which one is the best. This allows different ideas to be expressed 
quickly without a massive investment. 


Financial risk 1s what causes most companies to fail. They’ve built something 
cool, but they can’t sell it for enough to actually make a profit. A classic example of 
this is online journalism and the death of the newspaper. When the web first exploded 
in the nineties, newspapers were eager to get their content on the Internet. Some 
newspaper chiefs figured that, off-line or on, people would pay to advertise, so they 
made the content free. The problem, of course, was that advertisers were willing to 
pay far less money for online ads than print ads. Yet the cost of producing content 
remained the same. Others tried to put up pay walls in front of their content, but there 
were so many sites offering news for free that they were often forced to follow suit. 
Having actual reporters go places and witness things is expensive. You can see the 
results in the shuttering of newsrooms across the country. 


This idea of providing content or a service for free, and then making money on 
the advertising, is still prevalent in tech start-ups to this day. Entrepreneurs look at 
Facebook or Google and say, “I can do that.” The problem is that there just aren’t that 
many Facebooks and Googles. In the Internet’s early days, when online space first 
allowed companies to target particular customer segments, “hyper-focusing” was seen 
as valuable. But as more and more platforms have arisen to facilitate it, the capability 
doesn’t quite have the same allure. 


Another way that companies fall apart financially is by overpaying to acquire 
customers. One example is daily-coupon companies such as Groupon and Living 
Social. At their inception, they acquired customers quickly and easily. But as they 
expanded their reach and built up their head count, 1t became more and more costly to 
attract additional advertisers and more people willing to buy a coupon. You can see 
the results in these companies’ valuations. 


What Scrum does for business is answer the key question fast: Will we make 
money making this? By putting incremental releases in front of customers quickly, 
you'll find out what your customers value and what they’re willing to pay for. And if 
your first guesses were wrong, you can make changes. The most you can lose is the 
cost in time and energy of the few Sprints you invested—as opposed to the 


multimillion-dollar cost of building a huge complicated infrastructure, only to find out 
that, while people loved your product, they didn’t love it enough to pay for what it 
cost to make it. 


Here’s What You Do Tomorrow 


Okay, what do you do tomorrow to implement Scrum where you work? The first step 
is just putting together a Backlog and a team. Think about the vision you have for your 
product or service or whatever, and start breaking down the things you need to do to 
execute that vision. You don’t need a whole lot—just a week’s worth of Backlog. And 
while the team members are holding their Daily Stand-up meetings and running their 
first Sprint, you'll be able to build up enough Backlog to keep the team busy for the 
next two Sprints. Always keep one eye on that Backlog, though, because as your team 
accelerates, they’ Il start delivering more than you thought possible. 


Then, as the Product Owner, put together a road map of where you think things 
are going. What do you think you can get done this quarter? Where do you want to be 
this year? It’s important to remember that this is just a snapshot in time, so don’t 
overplan, just estimate. You’re not creating a binding contract of deliverables; you’re 
simply setting down your thoughts on where you'll be in a while. Believe me, the 
picture wi// change. Perhaps radically. 


The reason for doing this type of planning is to create transparency within the 
organization. If you have a sales team, they need to know what features you’re working 
on so they can start marketing them. Leadership needs to have some idea of where the 
revenue is going to come from—also, when and how much. The key message is that 
everything is being done in the open. Anyone can see where your product is at any 
time. They can see the stories move across the Scrum board to Done. They can graph 
story points against time on a Burndown Chart and watch a nice, steady line move 
toward zero, or burn down. They know how many story points your team did last 
Sprint, and how many you’re estimating theyll do next. Know that as the Product 
Owner you’re going to be evaluated on revenue and cost. 


What you'll quickly find, especially if you’re working in a place with multiple 
teams, is that you'll need to start putting together a Product Owner team so you can 
generate enough Backlog for the teams to plow through. You might have one Product 
Owner who focuses more on strategy and customer interaction, and another who’s 
more tactical, deciding what the teams will be working on during each Sprint. 


The important thing, though, is just to begin. Just start. You can see the detailed 
steps on how to do it in the appendix. Scrum is designed so that you can boot up a 
team in a couple of days. Get your Backlog, plan your first Sprint, and away you go. 
You don’t need to devote a lot of time to planning, reflection, meditations, mission 


statements, or five-year projections. Leave all that to the competition, and let them eat 
your dust. And along the way, why don’t you make the world a better place? In the 
next chapter, I'l] show you how. 


THE TAKEAWAY 


Make a List. Check It Twice. Create a list of everything that could 
possibly be done on a project. Then prioritize it. Put the items with the 
highest value and lowest risk at the top of that Backlog, then the next, and 
then the next. 


The Product Owner. She translates vision into Backlog. She needs to 
understand the business case, the market, and the customer. 


A Leader Isn’t a Boss. A Product Owner sets out what needs to be done 
and why. How the team accomplishes it and who accomplishes it is up to the 
team. 


The Product Owner: Has knowledge of the domain and the power to make 
final decisions. He or she is available to answer questions and is 
accountable for delivering value. 


Observe, Orient, Decide, Act (OQODA). See the whole strategic picture, 
but act tactically and quickly. 


Fear, Uncertainty, and Doubt. It’s better to give than to receive. Get inside 
your competition’s OODA loop and wrap them up in their own confusion. 


Get Your Money for Nothing, and Your Change for Free. Create new 
things only as long as those new things deliver value. Be willing to swap 
them out for things that require equal effort. What in the beginning you 
thought you needed is never what is actually needed. 


CHAPTER NINE 


Change the World 


Scrum has its origins in the world of software development. Now it’s sweeping 
through myriad other places where work gets done. Diverse businesses are using it for 
everything from building rocket ships to managing payroll to expanding human 
resources, and it’s also popping up in everything from finance to investment, from 
entertainment to journalism. I’m often amazed that a process I pioneered in 1993 to aid 
software development has proven itself universally applicable. Scrum accelerates 
human effort—it doesn’t matter what that effort is. 


In fact, ’ ve begun to see it spring up in the most unlikely places, addressing the 
thorniest of humanity’s problems. Think about some of those problems. For example, 
people living in poverty, which is not only demeaning but spawns a host of social ills, 
from crime and corruption to war and destruction. Then there’s our system of 
education, which is failing students the world over. Instead of teaching twenty-first- 
century skills, we’ve mired our young people in ways of teaching and learning created 
in the nineteenth century. And the other out-of-whack element that comes to mind is 
government, which has seized up in many ways, predicating itself on ideas formed 
hundreds of years ago that no longer seem to fit with the way we live our lives. 


It’s easy to throw your hands up at the latest news of people dying in Africa, 
violence in our schools, or the endless posturing of people in power. It just seems like 
too much at times. But those problems, the hard problems, are precisely what Scrum is 
designed to address. In each of those cases people are now turning to Scrum to help 
solve those problems, and, just as in the business world, they're showing remarkable 
SUCCESS. 


Education 


In some ways bedroom communities are the same the world over. Lying a few miles 
outside a major metropolis, they’re where people move to buy a cheaper house, raise 
a family, and send their kids to school without many of the problems of the big city. 


Alphen aan den Rijn 1s a pretty typical town in that sense. It lies in the west of the 
Netherlands, between Leiden and Utrecht, maybe forty-five minutes from Amsterdam. 
As you approach the town by road on a school day, all the traffic is headed in the other 
direction—to jobs elsewhere. Dairy farms and windmills, old and new, cover the 
countryside. 


Inside the town the traffic is almost all bicycles. Hundreds and hundreds are 
headed to the local public secondary school, Ashram College. The school, like the 


town, is fairly typical for a Dutch school. There are about 1,800 students ranging in 
age from twelve to eighteen. Holland tracks its students early, splitting the children 
among: lower vocational programs, aimed at producing everything from hairdressers 
to mechanics to secretaries; higher vocational programs, aimed at gearing kids toward 
nursing, management, and engineering; and university-bound programs, aimed at those 
heading for medicine, the law, or research. The kids on the lower tracks can enter the 
workforce at sixteen, while those in the higher track might spend much of their 
twenties in university and professional education. Each of the different tracks requires 
some core classes in common, though each group is taught those subjects separately. 
Ashram teaches all three tracks. And one of those core subjects is what Willy 
Wijnands teaches to students at every grade level in the school: chemistry. 


I’m sure you have memories of high school chemistry: lab tables in straight rows 
facing the teacher at the front of the room, perhaps a week of lecture followed by a 
few days working on a practical problem with a lab partner, the choice of whom was 
often strategic and much stressed over. Maybe you liked chemistry, maybe it bored 
you to tears, and maybe Breaking Bad gave you a new appreciation for the potential 
monetary reward of good lab technique and the importance of picking the right partner. 
Whatever your experience, once the teacher began talking about covalent bonds or 
some other abstruse concept, there was likely a near-audible click as you and your 
fellow students gazed out the window, doodled pictures, or thought about the cute boy 
or girl in the second row. Let’s face it, in the American classroom, where chemistry 
leads, daydreaming often follows. 


That’s not what happens in Wijnands’s classes, though. “See,” he says as the 
students burst into the room and hurry to their desks—oddly, without sitting down. “I 
don’t do anything.” It’s 8:30 a.m. on a normal Wednesday in September, and 
Wijnands’s classroom does not look like one. None of the desks are in rows facing the 
front of the room. Instead, they’re positioned so groups of four students can face one 
another. 


Instead of sitting down at the beginning of class, these students pull out a large 
piece of paper covered with sticky notes, put it on the wall, and gather around. The 
paper is divided into a few large columns. Alle items, on the far left. Then Ze doen, 
then /n uitvoering, and finally, Klaar. As you might guess, they mean “AII Items,” “To 
do,” “In Progress,” and “Done.” 


— susan’ ® Bee 


At the bottom of the columns are four additional headings: D.O.D, or Definition 
of Done; “Grafiek,” which points to their Burndown Chart showing progress toward 
their goal; and, lastly, Retrospective and Velocity, where they measure how many 
“points” they accomplish during each lesson. Their Sprints are usually four or five 
weeks long, ending with a test. 


In front of their Scrum boards—or “flops,” as they call themin Dutch (a 
derivation of the word for “flip chart’)—the students plot what lessons they’re going 
to finish today. They move the sticky notes they think they can accomplish from the 
Backlog, Alle items, to Te doen, and get to work. Again, as Wijnands likes to say, he 
does nothing. The students open their books and start to teach themselves. Perhaps 
more important, they teach one another. Wijnands walks the room, looking at the 
Scrum boards and Burndown Charts. Occasionally, he’ll spot a place where the 
students are having a problem, or he’ll quickly explain a tricky concept, or he’ll 
randomly take a story from the K/aar column and quiz each student on it, making sure 
all understand the concepts. If they don’t, he moves it back to Ze doen. Part of the 
Definition of Done, you see, is that everyone understands the material. 


The students do have one part of the Scrum board that is unique to them: a 


“Definition of Fun.” Not only does the work have to be complete, they also need to 
enjoy doing it. The three tests are Trust, Humor, and a uniquely Dutch word, 
Gezelligheld. There’s no good English translation for it. It’s described as “coziness,” 
or “companionability,” or “fun,” or “pleasant,” or seeing a friend after a long absence, 
or spending time with loved ones, or simply belonging. Actually, that strikes me as a 
perfect way to describe the feeling of support, enjoyment, hope, joy, comfort, and 
excitement of being on a really good team. 


“You don’t have to be the police,” says Wijnands. “We now have another way to 
deal with managing students. They do everything. They even assign themselves 
homework!” Each team knows where they are in the material, the dates by which they 
have to accomplish interim steps, and if they’ll need to do work outside of class to 
learn all the material in time. “They are self-organizing; they develop smarter and 
faster ways to study. One team started with the test and worked backward. A bunch of 
eleven-year-olds. ‘Not good,’ I told them. Their faces fell.” Wijnands grins his 
contagious smile. “Then I said, ‘Excellent!’ ” 


Scrum, or eduScrum, as Wijnands calls his approach, is introduced to the 
students on the first day of class. The first thing they do is choose teams—cross- 
functional teams. Students rate themselves in various categories, everything from 
bravery to math enjoyment to taking account of others’ feelings to “heading straight for 
the goal.” Then the students are told to form teams that are cross-functional, that have 
all the skills needed to learn the material. This, says Wijnands, teaches them 
something just as important as the chemistry—it teaches them how to work with, and 
appreciate, people with different talents than their own. 


Tim Jansen is seventeen years old. It’s his senior year. He’s now been doing 
Scrum for three years and is about to head to university, where he plans to study 
chemistry. He looks like your typical geek. “I am someone who can learn faster than 
others,” he says. “But working together, you improve, you get better. I learn the 
material better by explaining it to others.” He turns to Gudith Zwartz, who is sitting 
across the table from him. “She knows she can ask about content. I can ask her about 
organization. She can put it together better than I can.” 


Gudith looks quite different from Tim: slender, pretty, blond. “You get to know 
more about your classmates. You know who is good at which thing.” 


“Scrum helps the outsiders connect with the other parts of the class,” chimes in 
her equally pretty and stylish friend Maneka Bowens. “Sometimes you choose the 
team, and sometimes you get chosen. You learn they are better than you at some 
qualities.” 


That kind of learning, says Wijnands, is part of the 1dea—to make unconscious 


skills conscious ones. Skills that can be tested on an exam are far from the only 
important ones. Helping students learn to identify and value different strengths in 
themselves and others is a twenty-first-century skill. That’s something everyone needs 
to learn. 


After they pick teams, the students are taught how to estimate not in hours or days, 
but in points. They then estimate each piece of the material they need to learn using the 
relative sizing inherent in the Fibonacci sequence by playing Planning Poker. Willy 
explains the idea of points quite simply. “Ignore all the measures you were told. There 
are no absolute measures. If I weigh fifty points,” he says, pointing at a slender high 
school girl, “how many points do you weigh?” 


“Um, forty?” She guesses. 
“Why, thank you! I’d guess more around twenty, though.” 


At the end of each set of lessons, the teams do a Retrospective, asking 
themselves: “What went right?” “What could have gone better?” and “How can the 
team improve?” 


This focus on teams, says Wijnands, is sometimes surprising to parents. He tells 
the story of one mother who called up and said that her daughter had done all the 
work. Why was she being forced to carry everyone else? 


“T said the girl had to have the courage to tell others to do more. She did, and test 
scores went up. The mother called back to thank me. The students need to learn not 
only to work for themselves, but to work together.” 


The energy in the classrooms at Ashram is remarkable, and it translates into 
results. In the Dutch school system evaluative grades run from | to 10, and 5.5 is 
considered an acceptable passing grade. In Willy’s classes a 7 1s acceptable. And the 
students meet that baseline. Over the past year, says Wijnands, test scores have 
jumped more than 10 percent. 


Willy learned about Scrum from his son-in-law, who works at a large technical 
company in the Netherlands that uses it. Willy’s been a teacher for nearly four 
decades, and he says this is what he’s been searching for the whole time: an approach 
that teaches children to teach themselves and to value their own skills and those of 
others. Also, to have fun while doing so. 


An important thing to say about Scrum is that it rarely remains a one-off for long 
—it’s built to scale. In the Netherlands schools, for example, eduScrum is not 
dependent on one person, even as great a teacher as Wijnands. While it may have 
started with Willy, and he may have convinced a few of his fellow chemistry teachers 
at Ashram to give it a try, it’s now growing. Supported by the business community, 


there’s now aneduScrum Foundation in the Netherlands that trains teachers and 
educates schools about Scrum. They’ve trained seventy-four teachers so far—in all 
subjects in twelve schools. They plan on growing by sixty teachers and fifteen schools 
a year. In five years, that will mean 300 more teachers and 75 more schools. A good 
start. I met with a few of the teachers from across the country, and they told me that 
this is the new Montessori. They see this as a movement. 


It’s not just happening in the Netherlands, though. In Arizona there’s a charter 
school for poor, rural, Native American students that uses Scrum. In a few universities 
they are starting to teach it. At the Harvard Business School (HBS) they’ve built a new 
classroom called the “Innovation Lab,” where all the instruction is based around 
teams. And as Professor Hirotaka Takeuchi of HBS told me, when you teach teams, 
the way to do it is Scrum. 


While I was at Ashram, I spoke with some of the students there. When I asked 
what questions they had, one boy raised his hand. 


“T can’t believe you designed this for computer software,” he said. “It seems 
perfectly designed for high school.” 


I felt tears in my eyes as I looked at this young man. | learned later he was 
autistic. Before Scrum he’d been unengaged and resigned. Scrum had given him a way 
to move forward, to actually enjoy school, and to become a better, more complete 
person. 


Years ago, when I was trying to fix a few software companies, I hadn’t realized 
that I was also creating something that could help fix people’s lives. But it has. And 
perhaps nowhere more powerfully than in rural Uganda. 


Poverty 


Uganda is one of the poorest countries in the world. More than a third of the people 
there live on less than $1.25 a day. The vast majority of Ugandans reside in rural areas 
where poverty is endemic and people struggle to subsist by farming small family plots. 
Many of these places are beyond remote—days by foot from the nearest market town. 
Families have a hard time sending children to school, since their hands are needed to 
help on the farm. Girls especially drop out early. Life expectancy is fifty-three years. 
Infant mortality is more than 5 percent of live births, and about six thousand women 
die each year from complications in pregnancy. The life of a rural farmer in Uganda is 
not an easy one. 


The Grameen Foundation grew out of the Nobel Prize—winner Muhammad 
Yunus’s Grameen Bank, which pioneered microfinance for the extremely poor in 
Bangladesh. The Foundation focuses on helping lift the world’s poor out of poverty, 


not by handouts but by harnessing the underappreciated strengths of the impoverished. 
In Uganda they decided to try to do just that, by giving the poor the ability to share and 
build knowledge. 


To do it, they recruited some 1,200 people in poor, rural areas—people they 
called “Community Knowledge Workers” (CKWs). The Foundation had already 
developed mobile applications for microfinance and payments, and they decided to 
give these knowledge workers not just banking information, but information they could 
use in their daily lives, which, in Uganda’s case, meant it would be applied to 
farming. The Foundation provided access to the best agricultural practices by giving 
the workers smartphones and conveying the information that way. 


Steve Bell, of the Lean Enterprise Institute and a Certified Scrum Master, 
recently visited two remote villages and described how it works. There’s a meeting of 
farmers, standing up in a field. One farmer brought in a plant suffering from a disease. 
The CKWs quickly looked through pictures on the phone until they found a photo of a 
plant suffering from that particular disease. Then, instantly available was the scientific 
treatment for the disease—a treatment that didn’t require expensive pesticides or 
chemicals, one that the farmer could immediately act on. 


Bell says that fast transmission of actionable information would be powerful 
enough, but the app also links the farmers to others throughout Uganda. Using this 
connectivity, they can share precisely how much crops are selling for in the nearest 
market town, often days away. The farmers used to be at the mercy of middlemen 
who’d take advantage of the farmers’ lack of market knowledge to set prices at 
whatever level they liked. Now farmers know how much the middlemen are making. 


Bell told me the story of one woman who told him that the agricultural data alone 
doubled her yield. But the market data also doubled her prices. She used to get 300 
shillings a bushel, but after she learned they were being sold for 1,000 shillings a 
bushel, she was able to negotiate a price of 600 shillings. Double the yield, double the 
profit, the same amount of work. That’s what Scrum is designed to do, and that’s how 
it delivered for her. 


Eric Kamara heads the technology group for the Kinshasa office of the Grameen 
Foundation. His group uses Scrum to develop their applications. He says that each 
time a group asks for a feature set, his team rates it on a scale of | to 7 on three 
questions: 


1. How important is this work to the mission of helping the poor? 
2. How will this feature contribute to the work of the CK Ws? 


3. Is there partner support for the feature? (The Foundation prefers to work with 
partners such as the Gates Foundation rather than alone.) 


This allows Kamara to prioritize the work using objective criteria. Before 
Scrum, he says, people were asking for everything at once. And with the limited 
resources of a nonprofit, they couldn’t do everything, so the effect was doing nothing. 
Now in each Sprint the different groups who want features come in and pitch what 
they want done, and in a transparent way they see exactly how their feature stacks up 
against others. It helps a group with precious little to leverage determine what will 
have the greatest impact. 


As I’ve seen elsewhere, this kind of work quickly spreads to the rest of the 
Kinshasa offices, changing the way they do their nine-to-five jobs. The office used to 
have the sort of weekly meeting that everyone dreads—an hours-long status update 
during which problems were stated and complained about, but little was done. The 
meeting lasted forever, and everyone left unsatisfied. Often the only result was laying 
blame rather than seeking solutions. Now, Kamara says, every team has a Scrum 
board. Before the meeting, problems and blockages become easily apparent. These 
days the director of the office can simply walk around and instantly see where things 
are being blocked or stymied, just from checking out the state of the Scrum board. 


If you talk to people in the world of nongovernmental organizations (NGOs), a 
common complaint is that their ranks are filled with people who share purpose and 
commitment but lack discipline. What Scrum can do is take people’s passion and, by 
giving them clarity regarding what they should prioritize, harness it. 


It’s easy to make the business case for Scrum. If you use it, you’ll make more 
money—a lot more. You'll get twice as much done in half the time. But the brightest 
promise for humanity lies with those people who’ve devoted their lives to helping the 
poorest of the poor. If Scrum can help these individuals who’ve been working on the 
margins to get the same effect, a giant step will have been made toward achieving a 
broad social good. 


Not only will that “good” arrive sooner, it will also be measurable. Scrum gives 
people the ability to measure progress easily. At the Grameen Foundation they have 
what they call the “Progress Out of Poverty Index.” It measures just how effective 
each program is. They can poll andsee exactly the impact those Community 
Knowledge Workers with cell phones in rural villages are having. They can 
experiment with different ways of doing things. They can help people innovate their 
way out of poverty. 


For me, it’s amazing to see Scrum returning to its roots. When I first started 
Scrum, I was inspired by the Grameen Bank and other microfinance institutions and 


how they helped teams of poor people work together to leverage themselves out of 
poverty. They’d get together a team of them and have each person come up with a 
business plan laying out what they’d do with $25. One might want to buy a cart to sell 
fruit in the town square. Another might want to buy a sewing machine to make dresses 
she could sell. Only when all the loans on the team were paid back would the group be 
lent any more money. They’d meet each week to see how they could help one another. 
The results were amazing. Initially the woman with the sewing machine might make 
enough money to feed her children. A few weeks later she might be able to afford 
shoes for them. Then she could send them to school. A few cycles later she’d have a 
small business and could start building a real house. At the time, I told the software 
programmers I was working with: “These poor people have no shoes, and yet they can 
leverage their way out of poverty. You have shoes but no software. They’ve figured a 
way to work together to get out of misery. Are you willing to do the same?” And so 
Scrum was born. 


Nonprofits are just one area where we can innovate social good. What about how 
we organize ourselves? What about government? 


Government 


Government is not only how we organize the public sphere—how we get roads and 
police and courts and the DMV—it’s also how we formalize who we are as a people. 
It is a codification of who we believe we are. In the United States the fundamental 
aspirations of the American people are captured in a document signed by a bunch of 
rebels who surely would have been hanged separately if they didn’t “hang” together— 
the Declaration of Independence. Penned by an aristocratic, idealistic, slaveholding 
landowner, the Declaration, surprisingly, captured a radical concept of what kind of 
people revolutionary era Americans wanted to be. 


We hold these truths to be self-evident, that all men are created equal, that they 
are endowed by their Creator with certain unalienable rights, that among these 
are Life, Liberty, and the pursuit of Happiness. That to secure these rights, 
Governments are instituted among Men, deriving their just powers from the 
consent of the governed. 


It’s hard to appreciate in the modern day what a departure from the norm those 
words represented. While the ideas of the Enlightenment had begun to spread, there 
were no democracies at the time. Rule was imposed from above, from the divine right 
of kings and the power of arms. Great empires ruled much of the world—not only 
Great Britain, but also France, Austria, Russia, and Ottoman. The idea that individuals 
were endowed with rights, rather than granted them by the powerful, was, to put it 


mildly, revolutionary. 


The “republic” was a form of government that emerged from those ideals. Like 
Rodney Brooks’s robot learning to walk, the United States lurched to its feet, 
stumbled, fell, and occasionally wandered down the wrong path. But those ideals 
inspired revolutions the world over, and today most major powers are governed, at 
least in form, by the people they purport to represent. 


The problem, of course, is two-hundred-plus years of bureaucratic buildup— 
permanent interests embedded in the very structure of the government that make it hard 
for people’s voices to be heard. Corruption—whether on the small scale of 
bureaucrats taking bribes for services, or on the grand scale of large banks garnering 
wealth by privatizing profit and socializing loss—is a result of a lack of transparency 
and the centralization of power in the hands of the few. 


In most world capitals there has grown up a courtier class that constitutes the 
permanent government. Contracts are awarded, money is made, and power is 
conferred by “whom you know,” not by “what you bring.” Nowhere is this more 
evident than in the way politicians, generals, and powerful bureaucrats rotate from 
government to industry and back again. The number of four-star generals heading up 
defense contractors, or senators becoming lobbyists, or former administration officials 
heading up trade groups is staggering. 


But as I emphasized in chapter three, it’s pointless to look for evil people; look 
instead for evil systems. Let’s ask a question that has a chance to actually change 
things: “What is the set of incentives that drives bad behavior?” I truly doubt that any 
of the Beltway bandits sees themselves as bad people, and I’d bet that most are truly 
well-meaning. It’s the system that has failed them, and us. But how do we change it? 
How do we encourage transparency, priorities, and accountability? You know the 
answer: Scrum. 


Let’s start a few thousand miles west of Washington, D.C., in the Washington 
state capital, Olympia. There, the past two administrations—first a Republican, now a 
Democrat—have embraced what they call Lean government. The current governor, Jay 
Inslee, said in a campaign interview in the fall of 2012, “A lot of what the state does 
is make decisions. We want to find a way to leave less paper on a desk.”! 


The governor’s plan has five points that could have been plucked from any 
campaign platform: 1. a “world-class” education system from preschool through 
college; 2. a “prosperous economy”; 3. making Washington a national leader in 
sustainable energy and a clean environment; 4. healthy and safe communities; 5. 
efficient, effective, and accountable government. 


These are not revolutionary goals. This is what people should expect from their 


government. The very fact that they sound clichéd is an indicator of their importance. 
A cliché, after all, is just a truth repeated enough times to become trite. But what’s 
different about Inslee’s administration is how they’re going about it. They’ ve dubbed 
their new approach SMART—Specific, Measureable, Attainable, Relevant, and 
Time-bound. In other words, they want to use Scrum. And, in fact, they are. 


The office of the Chief Information Officer of the State of Washington is 
responsible not only for what technology is purchased, but how it’s made. The CIO’s 
office is made up of twenty people who are supposed to make sure massive IT 
failures, costing tens of millions of dollars, don’t happen. Meanwhile, the department 
handles IT upgrades for the parts of the government that do everything from issue 
driver’s licenses, to distribute unemployment benefits, to regulate fish and wildlife. In 
2012 they oversaw eighty requests totaling more than $400 million. And they issue 
standards and guidance to various agencies on how to implement state policy. 


To do that, they use Scrum. They’ ve actually torn down the cubicle walls in their 
offices and formed into Scrum teams. 


Michael DeAngelo, the Deputy CIO, says they try to deliver actionable, 
implementable policies to state departments every week: “We’re updating our process 
for how our agencies submit plans for investment. We set the goal that every week 
we're going to change one thing. We’re taking an incremental approach. We have a 
potentially shippable product every single week that can be felt by the agencies. They 
actually have something tangible.” “Shippable product,” in their case, means 
actionable changes to policy. It doesn’t have to be a thing; it just has to be something, 
anything, that creates value. 


Instead of trying to create a grand, overriding document anticipating every piece 
of the funding process, they’ ve decided to do it piece by piece. They want to deliver 
improvements in how the state is run every single week. 


Reaction, says DeAngelo, has been mixed. There’s a huge fear of not having a 
perfect product. Speaking in August of 2013 he said: “Just last week we made a 
change to how customers call us. But there’s a lot of documentation where we still 
have the old way listed—on our website, documents, that kind of thing. So there was 
all this other stuff we would have to change [first]. We decided not to wait, to just do 
it. We’ ll update documentation in the next Sprint. The alternative is that we don’t give 
them a better way for months ... we’re robbing them of value.” 


The other thing the CIO’s office is doing is trying to push Scrum through the 
entire state bureaucracy. It’s why they’ve changed their own processes to Scrum—to 
become an example, to be able to speak from experience. The benefits are just too 
great not to. 


But there are some roadblocks. DeAngelo says that one thing they’ve realized is 
that in some cases the Waterfall method is actually written into state law. Changing 
that can be tough. The State of Washington funds things in two-year cycles. “You have 
to ask for big chunks. You can’t say we’ll add value until you tell us to stop,” says 
DeAngelo. “The government wants to see [that] it’s going to cost this amount of 
money, [and that] we’ll get this amount of value in this time frame. That’s so they can 
talk about it with citizens. Even though we know it’s much more inefficient.” 


Part of the problem is that in the United States, both at the federal and state level, 
legislatures are broken into committees. One group of lawmakers looks at education, 
another at crime, another at the budget, and yet another at social services. 


“They are fractured. They never look at the whole picture,” says Rick Anderson. 
He’s a consultant to state agencies, counties, and cities in Washington, Oregon, 
California, and Hawaii. He has worked with the legislatures, and he says that while 
change may take a while, it has to happen. 


He thinks they should start setting performance-based goals. “Okay, Agency_X, 
here are your goals, here are your expected outcomes. Once you have that, you can 
start writing legislation that is outcome-based,” he says. 


In a revamped, Scrum-driven world, instead of approving a specific plan to build 
a bridge across a river, a legislative body would say to the highway department, ““We 
want X number of people to be able to travel over this waterway in Y amount of time 
with Z cost. How you do that is up to you.” That would allow for discovery and 
innovation. 


Instead, the norm these days is construction projects that run hundreds of millions 
of dollars over budget. The reason? As crews work on the project, they discover new 
problems and new ways of solving them. Instead of stifling that kind of innovation 
with Change Control Boards and massive reporting, we should be encouraging it. 


But what about those ideals that I started this section with—where a society 
shapes itself through a document? A constitution, say? Well, one country decided that 
the way to develop a constitution that truly represented the will of the people was to 
use Scrum. 


In 2008 a completely avoidable financial crisis hit the world. Big banks spun 
prices out of control, leveraging themselves over and over again by taking on more 
bad debt than could ever be repaid. One of the countries hit hardest was Iceland. 
Privatized banks there had been spun off by the government and had taken huge risks in 
the financial markets. As they say on Wall Street, if you don’t know who the sucker in 
the room is, you’re the sucker. In this case, Iceland was the sucker. The amount of 
money they borrowed was staggering for such a small country. Eventually, the banks 


had valuations twelve times the size of the national budget. When it all came crashing 
down, the Icelandic “economic miracle” was in tatters. 


In an expression of outrage, the citizens of Reykjavik took to the streets and 
banged pots and pans together outside the Althing, their parliament. The government 
that had overseen the financial practices collapsed in what became known as the “pots 
and pans revolution.” The government stepped down, and new leadership promised a 
new constitution. 


To write that constitution, some officials decided to be open and engage with the 
people. So they formed a constitutional committee, which decided to use Scrum. Each 
week the committee would meet, decide on one section of the document, and deliver it 
to the public every Thursday. Then they’d collect feedback from the people through 
Facebook and Twitter. In just a few months they had a new document that had won the 
overwhelming support of the Icelandic public. It was a new expression of how they 
saw themselves. 


Unfortunately, the powers that had benefitted from the financial fraud struck back. 
After filing delay after delay—after obfuscating, complaining, and acting against the 
will of the people—a new parliament made up of the same parties that oversaw the 
destruction of Iceland’s economy decided to simply ignore the new constitution. A key 
demand of the revolution was denied. For now, anyway. 


The world is changing, and those who profit from secrecy and deception will 
soon find they have few places left to hide. Scrum is changing the world around them, 
and while they may fight a rearguard action, change is inevitable. The Scrum 
framework is just so much faster, transparent, and responsive to the wishes of the 
people that it will ultimately defeat the politicians who stand in its way. 


Change or die. 
How We'll All Work One Day 


Earlier in this book I discussed the martial arts concept of Shu Ha Ri. People in the 
Shu state follow the rules exactly, so they learn the ideas behind them. People in the 
Ha state begin to create their own style within the rules, adapting them to their needs. 
People in the Ri state exist beyond the rules; they embody the ideals. Watching a true 
master in the Ri state is like looking at a moving work of art. His or her actions seem 
impossible, but that’s because the master has become a philosophy in flesh, an idea 
made real. 


All of which is to preface the fact that there are some rules in Scrum, and you 
would do well to both learn and transcend them. I’ve included them as an appendix to 
this book, “Implementing Scrum—How to Begin,” and I’ve written chapter after 


chapter on why those rules exist, encouraging you, I hope, to apply them in your 
personal life, your company, and your community. The paradox of those rules, though, 
is that they eliminate boundaries, they create freedom—and for many, freedom can be 
terrifying. 

One company that has learned how to set its employees free and optimize 
innovation is Valve. To look at the firm is to behold how we all may inevitably 
organize ourselves, whether it’s to make better software, raise people out of poverty, 
plan a wedding, or fix up a house. 


Formed in the 1990s as a videogame company making revolutionary hits such as 
Half-Life and Portal, Valve is completely self-funded and owns all its own 
intellectual property. Almost all of its 300-plus employees are located in a single 
office tower in Bellevue, Washington. The company has over fifty million customers, 
and it makes hundreds of millions of dollars a year. And no one 1s really in charge. 


Valve’s origin is, of all places, Microsoft. Nowadays Microsoft is a very 
different company, but back in the 1990s it was the epitome of the top-down 
corporation. Everyone defined themselves by how far down the corporate pyramid 
they were from founder and CEO Bill Gates—back then the richest man in the world, 
and still one of the richest. 


Greg Coomer is among the group of people who founded Valve. He worked for 
Gabe Newell, who headed a development group at Microsoft. Greg describes how 
that hyper-attentiveness to stature played out in the very tools people used: “At 
Microsoft there was an Outlook plug-in called ‘Org Chart.’ And any e-mail anyone 
would get, they’d click on that and see where the sender fit in the company. How many 
clicks away from Bill they were, how many direct reports they had, were they an 
enemy or a friend—all this could be discovered just from their position in the Org 
Chart.” 


Greg says that if you zoomed out, you could see that there was this giant pyramid 
with Bill at the top. If you zoomed in, there were bunches of smaller pyramids. “It was 
pyramids all the way down.” 


Except for Gabe Newell’s group. There were a few hundred people in it, and 
they all reported directly to him. “It stuck out visually in the ‘Org Chart’ app,” says 
Greg. “It was something that didn’t fit. And it was causing political problems, because 
he didn’t have the right number of managers or the right structure.” The company’s 
response was almost like that of white blood cells massing to attack an infection. 
Now, of course, Microsoft already has three thousand people working on Scrum teams 
and is moving toward some twenty thousand people. But back then this “infection” had 
to be removed. 


So Gabe, Greg, and a few others left and formed their own company, Valve. A 
few years ago Greg tried to compose an employee handbook explaining how Valve 
works. The document didn’t list pay grades or whether glasses were covered by the 
flex spending account. Rather, it was an attempt to convey the Valve ethos. 


“T figured out it was taking nine to sixteen months for people to internalize the 
Valve way of doing things. It took a long time for people to feel empowered,” says 
Greg. The document was intended to ease people in quicker, but Greg and the other 
founders struggled with the words, because they didn’t want it to seem that the 
explanation was coming from on high. The first section is “Welcome to Flatland”: 


It’s our shorthand way of saying that we don’t have any management, and nobody 
“reports to” anybody else. We do have a founder/president, but even he isn’t your 
manager. This company is yours to steer—toward opportunities and away from 
risks. You have the power to green-light projects. You have the power to ship 

products. 

A flat structure removes every organizational barrier between your work 
and the customer enjoying that work. Every company will tell you that “the 
customer is boss,” but here that statement has weight. There’s no red tape 
stopping you from figuring out for yourself what our customers want, and then 
giving it to them. 

If youre thinking to yourself, “Wow, that sounds like a lot of 
responsibility,” you’ re right.2 


Here’s how a project starts at Valve. Someone decides to start it. That’s it. They 
figure out what they think is the best use of their time and energy, what will serve the 
company and the customer the best, and they do it. How do they get other people to 
work with them on it? They convince them. If that other person thinks it’s a good idea, 
they’ Il join that team, or “cabal,” as it’s called at Valve. All the hundreds of desks at 
Valve have wheels. As people start to work together on a project, they literally vote 
with their desks, moving them into a new configuration. 


Greg describes the way it worked for a product called “Big Picture.” One of 
Valve’s biggest products is their Steam platform. It delivers videogames and software 
to users. Both Valve games and third-party games are on the platform. It’s the 
dominant way PC games are delivered today. But as Greg recalls, at one point he and 
a couple of others feared they were already reaching as many customers as they could, 
more than fifty million. 


“| We] started thinking about how our company was growing and how Steam is 
growing, and we were looking at what we thought would be the limit on the number of 


customers we could reach. We wanted to reach people in other places, in their living 
room, on mobile devices, whatever.” 


So he started talking to people—some designers, some other folks. He convinced 
them it was a good idea to come up with something that would work on televisions, 
phones, and tablets, and they created the idea of Big Picture—a way to deliver 
videogames to those platforms. But the people Greg had convinced didn’t have all the 
skills needed to actually make it. They knew what they wanted it to look like, but they 
didn’t have the ability to implement it. 


“So we started mocking up what it could look like, and then we made a movie of 
how cool it would be. And we used that movie to recruit people to the project. We 
couldn’t code it, [so] we needed to recruit people who could.” 


So they did. It shipped about a year later. Who decided when to ship it? The 
people who worked on it. Who decided it was good enough? The people who worked 
on it. 


“When a company has optimized itself around innovation, they usually change in 
a fundamental way by eliminating internal structures and hierarchies, any internal 
structure,” says Greg. Valve operates that way all the time. They don’t wait to be 
forced into change by a crisis; they are constantly changing. It’s the day-to-day way 
they run the company. From the Valve Handbook: 


Valve is not averse to all organizational structure—it crops up in many forms all 
the time, temporarily. But problems show up when hierarchy or codified 
divisions of labor either haven’t been created by the group’s members or when 
those structures persist for long periods of time. We believe those structures 
inevitably begin to serve their own needs rather than those of Valve’s customers. 
The hierarchy will begin to reinforce its own structure by hiring people who fit 
its shape, adding people to fill subordinate support roles. Its members are also 


incented to engage in rent-seeking behaviors that take advantage of the power 


structure rather than focusing on simply delivering value to customers.2 


It may seem that Valve would be vulnerable to freeloaders—to people who want 
to take advantage of the system—but peer review is constant. Sure, people get to 
decide what to work on, but if they can’t convince anyone else it’s a good idea, maybe 
it really isn’t. Greg says that instead of having the /uxury of having someone tell you 
what to do, you have a group of peers telling you what they think of what you’ve 
decided to do. 


It isn’t a perfect system. No human organization is. But usually at Valve, 


personnel concerns are raised first by fellow team members talking with one another. 
They may bring in others to consult. It may result in feedback, a harsh corrective 
move, or even dismissal. But it’s a team decision. 


The exception occurred in 2013, when Valve developed a problem their system 
wasn’t quite able to handle. For the first time ever they hired a large group of people 
all at once. They had decided to branch into hardware and mobile, and they simply 
didn’t have the skills to do it. So they hired a bunch of people to tackle the problem. 


But hiring that many people simultaneously who weren’t acclimated to the Valve 
way of doing things caused problems. There were pockets of workers not making 
decisions in the traditional Valve way. They were telling other people what to do. 
And, most damning, not performing up to the high Valve standards. Normally, other 
team members wouldn’t tolerate that kind of behavior, but because everyone in the 
group was new, their peers didn’t have enough confidence in the Valve way to take 
action. 


“So a group of the core Valve people who have been around for a while took 
action to protect the Valve ethos. Even though they had to act outside of the ethos to do 
it,” says Greg. The company fired a few dozen people at once. Talking to Greg, you 
can tell he sees that as a failure. He describes it as an almost biological reaction, one 
that was oddly parallel to how Microsoft acted toward Valve’s founders: organisms 
attacking foreign invaders to protect the whole. 


“We’ve been talking a lot about what it means to our stated goals that we had to 
act outside them,” reflects Greg. “And how we can avoid it in the future. And not have 
to rely on a group of people who have been at the company a long time.” He stops for 
a moment and then says with confidence, “By this time next year we’ll have figured it 
out.” 


There’s a faith in what they’ve done. They’ve consistently sought to maximize 
human freedom, ability, and creativity. While there have been occasional hiccups, it’s 
just too powerful a way of operating not to be replicated over and over again. 


“This is a capitalist innovation as powerful as many industrial innovations that 
changed the nature of work,” he says. “It is so useful and so successful that there is no 
way it can’t be a force of change in the world.” 


Do they use Scrum? Well, says Greg, you walk down the hallway, and you see a 
lot of whiteboards on wheels covered with sticky notes. But they don’t force people to 
use it; they let people decide what process is right for them. As with most matters, 
Greg and the other founders refrain from telling anyone what to do. But a lot of 
Valve’s workers have decided that, given the choice to do anything, they choose 
Scrum. And that’s enough for me. 


You don’t see many companies like Valve yet. But more are appearing each day. 
And not only in software. Morning Star, the global leader in tomato processing, has no 
bosses. Each employee negotiates with other employees as to roles and 
responsibilities, whether they involve sales, driving trucks, or doing sophisticated 
engineering. With any company, first you have to get employees to set themselves free, 
and then you have to get them to accept the responsibility that comes with that. 


Or, as Funkadelic put it back in 1970, “Free your mind ... and your ass will 
follow.” 


What Can’t We Do? 


Cynicism is perhaps a rational response to despair, but it is one of the most corrosive 
of human states. The early years of this century have been rife with the elements that 
breed cynicism: senseless wars draped in patriotism, nihilistic terrorism 
masquerading as faith, greed cloaked in ideological righteousness, ambitious political 
courtiers pursuing their own selfish ends. 


The cynic will sigh knowingly and say, “That’s just the way the world works. 
Humans are essentially corrupt and selfish—pretending otherwise is just naive.” In 
that way they justify constraints and rationalizes limits. 


Over the past two decades I’ve delved deeply into the literature of what makes 
greatness. The surprising answer is that, fundamentally, humans want to be great. 
People want to do something purposeful—to make the world, even if just in a small 
way, a better place. The key is getting rid of what stands in their way, removing the 
impediments to their becoming who they’re capable of becoming. 


That’s what Scrum does. It sets goals and systematically, step by step, works out 
how to get there. And even more important, it identifies what is stopping us from 
getting there. 


Scrum is the code of the anti-cynic. Scrum is not wishing for a better world, or 
surrendering to the one that exists. Rather, it is a practical, actionable way to 
implement change. I know of Scrum projects aimed at delivering vaccines to 
endangered children, and of others intended to build houses more cheaply, eliminate 
petty corruption, catch violent criminals, eliminate hunger, and send people to other 
planets. 


None of the above are dreamy desires—trather, they’re actionable plans. Make no 
mistake, these plans will have to be inspected, adapted, and changed every step of the 
way, but they’re in motion. All around the world, rapid iterations are occurring, 
propelling us toward a better world. 


That’s what I hope you'll take away from this book: the knowledge that it is 


possible—that you can change things, that you don’t have to accept the way things are. 


can. 


All men dream: but not equally. Those who dream by night in the dusty recesses 
of their minds wake in the day to find that it was vanity: but the dreamers of the 
day are dangerous men, for they may act their dreams with open eyes, to make it 
possible. 


—T. E. Lawrence, Seven Pillars of Wisdom* 
Don’t listen to cynics who tell you what can’t be done. Amaze them with what 


THE TAKEAWAY 


Scrum Accelerates All Human Endeavors. The type of project or problem 
doesn’t matter—Scrum can be used in any endeavor to improve 
performance and results. 


Scrum for Schools. In the Netherlands, a growing number of teachers are 
using Scrum to teach high school. They see an almost immediate 
improvement in test scores of more than 10 percent. And they’re engaging 
all sorts of students, from vocational to gifted. 


Scrum for Poverty. In Uganda, the Grameen Foundation is using Scrum to 
deliver agricultural and market data to poor rural farmers. The result: 
double the yield and double the revenue for some of the poorest people on 
the planet. 


Rip Up Your Business Cards. Get rid of all titles, all managers, all 
structures. Give people the freedom to do what they think best and the 
responsibility to be accountable for it. You'll be surprised at the results. 
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APPENDIX 
IMPLEMENTING SCRUM—HOW TO BEGIN 


Now that you’ve read the book, here’s how to start a Scrum project in a nutshell. This 
is a very broad stroke description of the process, but it should be enough to get you 
started. The book was written to give you the why behind Scrum. This will, in an 
abbreviated form, give you the how. 


1. Pick a Product Owner. This person is the one with the vision of what you are 
going to do, make, or accomplish. They take into account risks and rewards, what 
is possible, what can be done, and what they are passionate about. (See Chapter 
Eight: Priorities for more.) 


2. Pick a Team. Who will be the people actually doing the work? This team 
needs to have all the skills needed to take the Product Owners’ vision and make 
it a reality. Teams should be small, 3 to 9 people is the rule of thumb. (See 
Chapter Three: Teams for more.) 


3. Pick a Scrum Master. This is the person who will coach the rest of the team 
through the Scrum framework, and help the team eliminate anything that is 
slowing them down. (See Chapter Four: Waste for more.) 


4. Create and prioritize a Product Backlog. This is a list at a high level of 
everything that needs to be built or done to make that vision a reality. This 
backlog exists and evolves over the lifetime of the product; it is the product road 
map. At any point, the Product Backlog is the single, definitive view of 
“everything that could be done by the team ever, in order of priority.” Only a 
single Product Backlog exists; this means the Product Owner is required to make 
prioritization decisions across the entire spectrum. The Product Owner should 
consult with all stakeholders and the team to make sure they are representing both 
what people want and what can be built. (See Chapter Eight: Priorities for 
more.) 


5. Refine and Estimate the Product Backlog. It is crucial that the people who are 
actually going to complete the items in the Product Backlog estimate how much 
effort they will take. The team should look at each Backlog item, and see if it is 
actually doable. Is there enough information to complete the item? Is it small 
enough to estimate? Is there a Definition of Done, that is, everyone agrees on 
what standards must be met to call something “done”? Does it create visible 
value? Each item must be able to be shown, to be demonstrated, hopefully to be 


potentially shippable. Do not estimate the Backlog in hours, because people are 
absolutely terrible at that. Estimate by relative size: Small, Medium, or Large. Or 
even better use the Fibonacci sequence and estimate the point value for each 
item: 1, 2, 3, 5, 8, 13, 21, etc. (See Chapter Six: Plan Reality, Not Fantasy for 
more.) 


6. Sprint Planning. This is the first of the Scrum meetings. The team, the Scrum 
Master, and the Product Owner sit down to plan the Sprint. Sprints are always a 
fixed length of time that is less than a month. Most people now run one- or two- 
week Sprints. The team looks at the top of the Backlog and forecasts how much 
of it they can complete in this Sprint. If the team has been going for a few Sprints, 
they should take in the number of points they did in the last Sprint. That number is 
known as the team’s Velocity. The Scrum Master and the team should be trying to 
increase that number every Sprint. This is another chance for the team and the 
Product Owner to make sure that everyone understands exactly how these items 
are going to fulfill the vision. Also during this meeting everyone should agree on 
a Sprint Goal, what everyone wants to accomplish with this Sprint. 


One of the pillars of Scrum 1s that once the team has committed to what 
they think they can finish in one Sprint, that’s it. It cannot be changed, it 
cannot be added to. The team must be able to work autonomously throughout 
the Sprint to complete what they forecast they could. (See Chapter Four: 
Time and Chapter Six: Plan Reality, Not Fantasy for more.) 


7. Make Work Visible. The most common way to do this in Scrum is to create a 
Scrum Board with three columns: To Do, Doing, Done. Sticky notes represent 
the items to be completed and the team moves them across the Scrum board as 
they are completed, one by one. 


Another way to make work visible is to create a Burndown Chart. On 
one axis is the number of points the team has taken into the Sprint, on the 
other is the number of days. Every day the Scrum Master tallies up the 
number of points completed and graphs them on the Burndown chart. Ideally 
there will be a steep downward slope leading to zero points left on the last 
day of the Sprint. (See Chapter Seven: Happiness for more.) 


8. Daily Stand-up or Daily Scrum. This is the heartbeat of Scrum. Each day, at 
the same time, for no more than fifteen minutes, the team and the Scrum Master 
meet and answer three questions: 


¢ What did you do yesterday to help the team finish the Sprint? 
¢ What will you do today to help the team finish the Sprint? 


¢ Is there any obstacle blocking you or the team from achieving the Sprint 
Goal? 


That’s it. That’s the whole meeting. If it takes more than fifteen 
minutes, you’re doing it wrong. What this does is help the whole team know 
exactly where everything is in the Sprint. Are all the tasks going to be 
completed on time? Are there opportunities to help other team members 
overcome obstacles? There’s no assigning of tasks from above—the team is 
autonomous; they do that. There’s no detailed reporting to management. The 
Scrum Master is responsible for making the obstacles to the team’s 
progress, or impediments, go away. (See Chapter Four: Time and Chapter 
Six: Plan Reality, Not Fantasy for more.) 


9. Sprint Review or Sprint Demo. This is the meeting where the team shows 
what they have accomplished during the Sprint. Anyone can come, not only the 
Product Owner, the Scrum Master, and the team, but stakeholders, management, 
customers, whoever. This is an open meeting where the team demonstrates what 
they were able to move to Done during the Sprint. 


The team should only demo what meets the Definition of Done. What is 
totally and completely finished and can be delivered without any more 
work. It may not be a completed product, but it should be a completed 
feature of one. (See Chapter Four: Time for more.) 


10. Sprint Retrospective. After the team has shown what they’ve accomplished 
during the last Sprint—that thing that is “done” and can potentially be shipped to 
customers for feedback—they sit down and think about what went right, what 
could have gone better, and what can be made better in the next Sprint. What is 
the improvement in the process that they, as a team, can implement right away? 


To be effective, this meeting requires a certain amount of emotional 
maturity and an atmosphere of trust. The key thing to remember is that you’re 
not seeking someone to blame; you’re looking at the process. Why did that 
happen that way? Why did we miss that? What could make us faster? It is 
crucial that people as a team take responsibility for their process and 
outcomes, and seek solutions as a team. At the same time, people have to 
have the fortitude to bring up the issues that are really bothering them in a 
way that is solution oriented rather than accusatory. And the rest of the team 
has to have the maturity to hear the feedback, take it in, and look for a 
solution rather than getting defensive. 


By the end of the meeting the team and the Scrum Master should agree 
on one process improvement that they will implement in the next Sprint. 


That process improvement, sometimes called the kaizen, should be put into 
the next Sprint’s backlog, with acceptance tests. That way the team can 
easily see if they actually implemented the improvement, and what effect it 
had on velocity. (See Chapter Seven: Happiness for more.) 
11. Immediately start the next Sprint cycle, taking the Team’s experience with 
impediments and process improvements into account. 
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